Hi Simon,
At 11:41 05/12/2016, you wrote:
On 5 Dec 2016, at 7:48am, Jean-Christophe Deschamps <j...@antichoc.net>
wrote:
> The choice of literals representing true and false is merely cosmetic.
You got me interested in that. I had thought that "TRUE" and "FALSE"
were reserved words in SQLite. But I can find nothing to back that up, and
SELECT TRUE
returns an error. Itâs too late to add them now, of course, for
backward compatibility reasons. Someone may have a table column
called "false".
Simon.
I'm as surprised as you about this, but it isn't the point I wanted to
make.
BTW SQLite generally does a pretty good job at sorting out reserved
words used as keywords vs. keywords used as schema names, but I always
recommend that double quotes surround reserved names used as schema names.
I meant that we could call the truth of a boolean expression
'STAINLESS' or 'RASPBERRY' instead of True and False, or 1 and 0. The
symbols or literals we use for expressing a boolean value is just a
convention. I wasn't talking especially about SQLite nor SQL (nor any
language).
Look at the various incompatible conventions for expressing boolean
values as "boolean-codepage nightmare" in that it reproduces, in the
{false, true} domain, exactly the same issues codepages have created in
character sets.
JcD
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
