I tracked down a perplexing issue to the following behavior:
sqlite> CREATE TABLE tab (col);
sqlite> SELECT nope FROM tab; -- fails; good
Error: no such column: nope
sqlite> SELECT "nope" FROM tab; -- works?
sqlite> INSERT INTO tab (col) VALUES (77);
sqlite> SELECT col FROM tab WHERE nope IS NOT NULL; -- fails; good
Error: no such column: nope
sqlite> SELECT col FROM tab WHERE "nope" IS NOT NULL; -- works?
77
It seems that "nope" is being interpreted as a string literal here,
while quoted names of valid columns are not:
sqlite> SELECT "nope", "col" FROM tab;
nope|77
I see that this is discussed briefly in the documentation, though the
exception as written only applies to quoted keywords, which "nope" is
not: <https://www.sqlite.org/lang_keywords.html>
But it seems especially surprising that the parse tree should depend on
the actual identifier values and table schemata, making the grammar not
context-free.
Is this working as intended? Are there plans to make SQLite reject such
examples as malformed queries instead of implicitly coercing?
My `sqlite3 --version`:
3.11.0 2016-02-15 17:29:24 3d862f207e3adc00f78066799ac5a8c282430a5f
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
