Per https://www.sqlite.org/draft/gencol.html thank you very much for adding this
generated columns feature!
I consider this to be a very powerful foundation for a variety of useful
features, in particular because it empowers generalized solutions to several
classes of problem.
In particular, this provides a generalized foundation for arbitrary unique
constraints and indexes.
Some SQL DBMSs have complicated syntax for declaring indexes or keys, say for
example case-insensitive uniqueness or indexing only a prefix of a character
string or various other things.
When generalized generated columns are supported as SQLite is going to do, the
syntax for key or constraint declaration can simply reference a column as a
whole and use the entire pristine column value; by default this means key or
index in a case-sensitive etc manner, but if there is a generated column that is
a lowercased version of a regular text field, one can put the unique constraint
on that column instead to get the case-insensitive uniqueness without
complicating the key/index declaration syntax to do so.
There is a lot of power here from such a basic foundation.
Related to this, I strongly encourage the SQLite developers to relax the
constraint on generated columns being used in a PRIMARY KEY sooner rather than
later.
Ideally a PRIMARY KEY would have no restrictions that a UNIQUE constraint lacks;
they are conceptually the same thing, a subset of the columns of the row that
uniquely identifies the row in the table, and designating one as PRIMARY is
completely arbitrary in that sense.
The benefits I ascribed to generated columns as a foundation would be greatly
weakened if a PRIMARY KEY can't use them.
Thank you.
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users