On Dec 24, 2015, at 7:49 PM, Simon Slavin <slavins at bigfraud.org> wrote: > > What makes "ALTER TABLE table-name DROP ?COLUMN" hard is checking the schema > to make sure that nothing in the schema refers to the dropped column.
Given that the current alternative to this feature is hand-rolled code like I gave earlier in the thread, I don?t see that SQLite *must* solve this problem. It would certainly be nice if it maintained consistency for you, but since the alternative doesn?t allow you to do that, what?s wrong with just putting a warning in the docs: ?If you use ALTER TABLE DROP COLUMN, you risk breaking consistency checks.? Then you can push off automatic consistency check maintenance to the quasi-mythical SQLite 4. Again, all I?m advocating for is automatic generation and running of the SQL I gave above. That is, implement the feature in terms of existing facilities, don?t go creating a bunch of new code just to handle this case. Not only does this make implementation easier, it will reduce the temptation to make the feature conditional to keep the embedded users happy, which in turn makes testing harder, since it doubles the number of test cases.
