On Oct 8, 2012, at 3:36 PM, Darren Duncan <dar...@darrenduncan.net> wrote:
> Petite Abeille wrote: >> On Oct 8, 2012, at 10:12 PM, Richard Hipp <d...@sqlite.org> wrote: >>> ALTER TABLE DROP COLUMN requires writing every row of the table. >> Could be a 'logical delete' instead. In other words, a dictionary operation >> instead of a data one. >> http://www.oracle-base.com/articles/8i/dropping-columns.php#LogicalDelete > > I don't think you want to follow the syntax of that Oracle example, the > "ALTER TABLE foo SET UNUSED (bar, baz)", especially since that is reversible > and it could mess up other issues such as effectively invalidating > constraints. > > *All* SQL actions are /supposed/ to be logical, meaning that DROP COLUMN *is* > a "logical delete", no matter if column data is physically removed or just > made inaccessible. > > SQLite can add the DROP COLUMN syntax but just implement it so that tables > don't have to be rewritten, but just that the then-superfluous table data is > ignored, and so you still get O(1). > > Of course, if that is done, then in order to have predictable performance > we'd also want to add some other statement one can invoke when they want to > reclaim disk space later, which actually goes and rewrites the table, rather > than this just happening "automatically" (though it could also be configured > to happen automatically. That would be VACUUM, which already rewrites the tables, and would have to be run to reclaim the space anyways. -j > -- Darren Duncan > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
