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 

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 
that unnecessary.

sqlite-users mailing list

Reply via email to