Mike Mascari <mascarm(at)mascari(dot)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
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Tatsuo Ishii||Date: 2000-03-07 08:06:43|
|Subject: Re: [HACKERS] DROP TABLE inside a transaction block |
|Previous:||From: Tom Lane||Date: 2000-03-07 06:58:22|
|Subject: Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST) |