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
