Description
Yep. For now, everything's quoted where it can be and because of this, relying and detecting dots is problematic because you could, in theory, have a table name with a period in it.
(from #30)
A downside of using quoted identifiers everywhere is that db errors might get obscured, e.g. in this example from the documentation:
let count = try db.scalar(users.filter(name != nil).count)
// SELECT count(*) FROM "users" WHERE "name" IS NOT NULLA missing name column will not raise an error. The reason is that identifiers can get reinterpreted as strings if the identifier is not found:
If a keyword in double quotes (ex: "key" or "glob") is used in a context where it cannot be resolved to an identifier but where a string literal is allowed, then the token is understood to be a string literal instead of an identifier.
(https://www.sqlite.org/lang_keywords.html)
Richard Hipp called this a "tragic design error":
The fact that SQLite will treat a double-quoted string as a string literal
rather than as a quoted identifier is a horrible mis-feature. It was added
10 years or so ago in an attempt to be more MySQL-compatible. I have come
to sorely regret that change. I'd love to get rid of this mis-feature, but
cannot do so now, since there are millions of applications in the wild that
use SQLite and some percentage of those (hopefully a very small percentage,
but still non-zero) will break if I remove the mis-feature.
The point is that allowing double-quoted strings is a tragic design error.
It's not really SQLite.swift's fault, but it would be good if the quoting could be overridden on a case-by- case basis.
I tried Expression<T>(literal: ...) but that does not work since column names are also quoted when fetched from the database. Even if this is not addressed in SQLite.swift itself it might be helpful to mention this peculiarity somewhere in the documentation.