Re: [HACKERS] DROP TABLE inside a transaction block - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] DROP TABLE inside a transaction block
Date
Msg-id 19326.952415629@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] DROP TABLE inside a transaction block  (Mike Mascari <mascarm@mascari.com>)
Responses Re: [HACKERS] DROP TABLE inside a transaction block  (Tatsuo Ishii <t-ishii@sra.co.jp>)
SCHEMA support (was Re: DROP TABLE inside a transaction block)  ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>)
Re: [HACKERS] DROP TABLE inside a transaction block  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Mike Mascari <mascarm@mascari.com> writes:
> So, as some sort of compromise, a NOTICE was issued.

It seems everybody but Mike has forgotten the previous go-round on
this issue.  I had in fact put in an ERROR for DROP TABLE inside a
transaction block, and was beat up for it --- on the very reasonable
grounds that it's useful to be able to drop a table and do some other
things inside a transaction.  Although we can't support rollback-ability
for such a transaction right now, we *do* support the atomic nature of
such a transaction.  It's not reasonable to take away a capability that
was available in prior releases just because it's got deficiencies.
So the compromise was to issue a NOTICE instead of an ERROR.

BTW, we are not *that* far from being able to roll back a DROP TABLE.
The only thing that's really needed is for everyone to take a deep
breath and let go of the notion that table files ought to be named
after the tables.  If we named table files after the OIDs of their
tables, then rollback-able DROP or RENAME TABLE would be pretty
straightforward.  If you don't recall why this is, consult the
pghackers archives...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] DROP TABLE inside a transaction block