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
