I need to parameterize a view, and I am doing so by creating a TEMP TABLE which has the parameters for the view.

CREATE TEMP TABLE parms (parm1 INTEGER, parm2 INTEGER);
CREATE VIEW tableview AS ...

The VIEW is rather complex, but it basically uses these two parameters to kick start a recursive CTE, and there isn't any other way that I have found to express the view without these parameters.

The parameters must be stored in a temporary table because each connection should be able to have its own view with different parameters.

In any case, this works fine for creating the view itself, so long as I create the same TEMP TABLE at the start of any queries that use the view, e.g.:

CREATE TEMP TABLE parms (parm1 INTEGER, parm2 INTEGER);
INSERT INTO parms (parm1,parm2) VALUES (5,66);
SELECT * FROM tableview;

I am able to do the same thing to create a trigger to allow inserts on the view:

CREATE TEMP TABLE parms (parm1 INTEGER, parm2 INTEGER);
CREATE TRIGGER tableinsert INSTEAD OF INSERT ON tableview ...

However, when I try to do an actual INSERT (re-creating the TEMP TABLE first as before) I get an error:

no such table: main.parms

If I create a non-temporary table, I do not get this error, but then I have the problem that different connections can't have their own separate views.

I have review the documentation for triggers, and it mentions caveats of using temporary triggers on a non-temporary table, but I don't see anything regarding the reverse.

I did find a reference elsewhere that indicated that "the table... must exist in the same database as the table or view to which the trigger is attached". I thought a temporary table was part of the current database, is this not true? Is there some way to make this true?

I also tried accessing the parms table as temp.parms in the TRIGGER, but got the error:

qualified table names are not allowed on INSERT, UPDATE, and DELETE
statements within triggers

If I can't use a temporary table, is there some way to work around it to accomplish the same thing?

Update: Ok, so it seems to be an SQLite limitation. After digging around a bit in the SQLite source code, it seems to be pretty trivial to allow SELECT access to a temporary table in a trigger. However, allowing UPDATE access appears to be a lot harder.