On 10 Jun 2018, at 2:18am, Andy Goth <andrew.m.g...@gmail.com> wrote:
> However, views make behavior of INSERT and UPDATE clear, since they can
> only operate on the real table. INSERT or UPDATE become murky when in
> the presence of computed columns. I suppose the only sane thing to do
> is forbid directly setting the value of a computed column, though what
> would the syntax be?
One cannot set the value of a computed column in INSERT or UPDATE. An attempt
to do so yields an error in both SQL SERVER and MySQL. Also, computed columns
are skipped in the form of INSERT where the columns are not named.
> Skip computed columns in the value list? If two
> tables have the same schema, this should duplicate one into the other,
> but apparently not:
> INSERT INTO table2 SELECT * from table1;
This syntax, when found with a computed column, would be something that the
SQLite engine would have to notice and act correctly. The same in the case of
CREATE TABLE ... SELECT ... .
There are a number of other niggles. For instance, creating and updating an
index which includes a VIRTUAL calculated column could be complicated and
time-consuming. It may be that for a computed column to appear in an index it
must be STORED. On the other hand, the way SQLite works internally might make
sqlite-users mailing list