I take it that this is a side effect of how the parser works: Given the sequence 'CREATE TEMP TABLE X ...', the parser knows that the required action is SQLITE_CREATE_TEMP_TABLE during prepare of the statement as soon as the token TABLE is accepted.
OTOH, given the sequence 'CREATE TABLE TEMP.x', the parser knows that the required action is SQLITE_CREATE_TABLE during prepare of the statement as soon as the token TABLE is accepted. Apparently, this is not updated when the schema name is parsed. -----Original Message----- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Joshua Thomas Wise Sent: Sonntag, 10. Februar 2019 01:17 To: sqlite-users@mailinglists.sqlite.org Subject: [EXTERNAL] Re: [sqlite] Inconsistent behavior in sqlite3_set_authorizer() and error messages I’ll interpret the silence as a “no”? > On Feb 7, 2019, at 11:53 AM, Joshua Thomas Wise <joshuathomasw...@gmail.com> > wrote: > > Is the SQLite team aware of these issues? > > >> On Feb 4, 2019, at 7:00 AM, sqlite-users-requ...@mailinglists.sqlite.org >> <mailto:sqlite-users-requ...@mailinglists.sqlite.org> wrote: >> >> Hello, >> >> I found some behaviors that should probably be considered bugs (and should >> be fixed and/or documented). >> >> Let’s start the explanation by observing some behavior that actually is >> correct and consistent. Below, we observe which type of action is reported >> by sqlite3_set_authorizer(), given some SQL input: >> >> "CREATE TEMP TABLE foo(x)” -----> SQLITE_CREATE_TEMP_TABLE "CREATE >> TEMP VIEW foo AS SELECT 1” -----> SQLITE_CREATE_TEMP_VIEW "CREATE >> TEMP TRIGGER foo BEFORE INSERT ON t BEGIN SELECT 1; END" -----> >> SQLITE_CREATE_TEMP_TRIGGER >> >> So far so good. But what happens when we use the “temp.foo” syntax instead >> of the TEMP keyword? >> >> "CREATE TABLE temp.foo(x)" -----> SQLITE_CREATE_TABLE "CREATE INDEX >> temp.foo ON t(x)" -----> SQLITE_CREATE_TEMP_INDEX "CREATE VIEW >> temp.foo AS SELECT 1" -----> SQLITE_CREATE_VIEW "CREATE TRIGGER >> temp.foo BEFORE INSERT ON t BEGIN SELECT 1; END" -----> >> SQLITE_CREATE_TEMP_TRIGGER >> >> Uh-oh. We have some inconsistencies there. CREATE TABLE and CREATE VIEW >> report their regular CREATE_* variants, while CREATE INDEX and CREATE >> TRIGGER do report their TEMP_* variants. >> >> I recommend that either all or none of those statements should report their >> TEMP_* variants to the sqlite3_set_authorizer() callback. If the decision is >> made to not use TEMP_* variants in these cases, the schema name (“temp”, in >> this case) should ideally be included as an argument to the >> sqlite3_set_authorizer() callback. >> >> I also found strange inconsistencies regarding error messages. If we execute >> the 4 statements above, but this time with the SQLITE_OMIT_TEMPDB >> compile-time option present, we get the following error messages >> (respectively): >> >> 'SQL logic error' >> 'cannot create a TEMP index on non-TEMP table “t”' >> 'SQL logic error’ >> 'SQL logic error’ >> >> However, if we replace “temp.foo” with “miss.foo” in each of those >> statements, we get the much better error message: >> >> 'unknown database miss’ >> >> All of the observations described in this email were very surprising to me. >> Hopefully they can be fixed and/or documented. >> >> Best regards, >> >> Josh > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick | Software Engineer | Scientific Games International GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 1 80100 - 0 May be privileged. May be confidential. Please delete if not the addressee. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
