Is the SQLite team aware of these issues?

> On Feb 4, 2019, at 7:00 AM, 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

Reply via email to