[sqlite] Shadowing a table name with a common table expression

If we create a table and then declare a common table expression of the same name, `SELECT`s seem to refer to the table, while `INSERT` targets refer to the CTE. For example: ``` CREATE TABLE foo (x); INSERT INTO foo SELECT 1; WITH foo (x) AS (SELECT 10) INSERT INTO foo SELECT x + 1 FROM foo;

Re: [sqlite] [EXTERNAL] Non-keyword quoted identifiers parsed as string literals

> This is documented behaviour. Use single quotes for literal strings. > SQLite will assume you meant 'literlal' if your write "literal" and > there is no column of that name. There is no need to quote names in > SQLite unless the name contains non-alpha characters. Thanks, yes. I was quoting the

Re: [sqlite] Non-keyword quoted identifiers parsed as string literals

Thank you both for your quick and helpful replies! The `quirks.html` page certainly clears things up. Glad to see that there are new options to disable this; I reached out to the maintainers of the language bindings that I use to see if we can get that enabled [1]. [1]:

[sqlite] Non-keyword quoted identifiers parsed as string literals

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

Re: [sqlite] Glob documentation clarity

I think that you can infer it from the statement that "The GLOB operator is similar to LIKE". The documentation for the "LIKE" operator notes explicitly that the right-hand operand is the pattern (needle) and the left-hand operand is the string to match against the pattern (haystack). That said,

Re: [sqlite] docs: application_id is signed, not unsigned

Update: drh fixed this in 3580ba4b5bd75ec6. Thanks! Best, WC ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] docs: application_id is signed, not unsigned

The docs for "PRAGMA application_id" read: > The application_id PRAGMA is used to query or set the 32-bit unsigned > big-endian "Application ID" integer located at [...]. However, it appears that the argument to this pragma is interpreted as a _signed_ integer, not an unsigned integer. In