On May 16, 2011 9:33 AM, "Simon Slavin" <slav...@bigfraud.org> wrote:
> On 16 May 2011, at 3:44am, romtek wrote:
>
> > Secondly, if I executed the above SQL code, what would happen to
triggers,
> > etc. that are associated with the original table?
>
> I suspect that's a major reason why SQLite doesn't support DROP COLUMN: it
has to check for things that might depend on the column and refuse to DROP
if it finds anything.

Nit: that's almost certainly the reason that SQLite3 doesn't support column
rename, and one reason it doesn't support column  DROP, but column drop is
almost certainly not supported primarily because of the way SQLite3 encodes
row data (namely, as a type-length-value sort of sequrnce encoding, with
location in the sequence having to match up to the table's column order).
Existing rows would then be utterly confusing.  The row data encoding is
also the reason that new columns can only be added and appear at the end of
the new CREATE TABLE statement, and also why they can only be added only
without NOT NULL or with constant expression DEFAULT values (column value
absence implies default constant value if one was specified).  (The row
encoding could have included a table schema version number at the front, but
then SQLite3 would have to keep around historical schemata.  Too complicated
for something "Lite".)

Nico
--
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to