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 that unnecessary. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
