It doesn't suprise me that it doesn't work, but I am surprised to get
into a half-baked state if an abort does happen for some reason.
NOTICE: Caution: DROP TABLE cannot be rolled back, so don't abort now
Probably what should happen is it should error out if you try to do
things like this in a transaction, or autocommit for you no matter what.
Whatever it takes to not be in a half-baked state.
Tim
Tom Lane wrote:
>
> "Mike Mascari" <mascarm@mascari.com> writes:
> > Rolling back DDL statements properly
> > in a MVCC transaction environment is very difficult, as
> > you can imagine. IIRC Oracle cheats, Informix and DEC Rdb
> > lock the DDL target until transaction commit, etc. If
> > the PostgreSQL team implements their stated goal in this
> > area, it will be far superior to its commercial counterparts.
>
> AFAIK we intend to keep the current behavior of exclusively
> locking any table you try to drop or modify. So it'll be
> pretty much like the Informix/RDB behavior.
>
> But yes, at the moment DROP or RENAME inside a transaction is
> pretty risky (and 7.0 tells you so, with an annoying NOTICE).
>
> regards, tom lane
--
Founder - PHPBuilder.com / Geocrawler.com
Lead Developer - SourceForge
VA Linux Systems
408-542-5723
