Thread: DROP TABLE in transaction
Hello. I was wondering if anybody could explain to me why I can't roll back dropping a table. I would think that of all the events that should be rollback-able, dropping a table would be the first on the list. -- Dave
David Olbersen writes: > I was wondering if anybody could explain to me why I can't roll back dropping a > table. Because DROP TABLE removes the table file on disk, and you can't roll back that. Actually, in 7.1 you can. ;-) > I would think that of all the events that should be rollback-able, > dropping a table would be the first on the list. Naah. Insert and update are first. ;-) -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Thu, 12 Apr 2001, Peter Eisentraut wrote: > Because DROP TABLE removes the table file on disk, and you can't roll back > that. Actually, in 7.1 you can. ;-) Well I understand that it's being taken from the disk, but why does that action have to be done *right now*? Why can't it be postponed until I type 'commit;' ? I wonder how much time this addition would have saved those of us who type quickly and use the tab-completion too much :) -- Dave
On Thu, 12 Apr 2001, David Olbersen wrote: > On Thu, 12 Apr 2001, Peter Eisentraut wrote: > > > Because DROP TABLE removes the table file on disk, and you can't roll back > > that. Actually, in 7.1 you can. ;-) > > Well I understand that it's being taken from the disk, but why does that action > have to be done *right now*? > Why can't it be postponed until I type 'commit;' ? > > I wonder how much time this addition would have saved those of us who type > quickly and use the tab-completion too much :) If one were inclined to do this sort of thing, it might even make sense to argue that DROP TABLE hides the table (sets an attrib so that it doesn't show, query planner doesn't see it, etc.); it should actually be removed from disk when the database on VACUUM. -- Joel Burton <jburton@scw.org> Director of Information Systems, Support Center of Washington