Re: tuple concurrently updated

"Kangmo, Kim" wrote:
> 
> How do you think about my suggestion to not versioning system catalogs?
> 
> p.s. It's unbelivable that I got a reply from legendary Tom Lane. :)
> 
> Best,
> Kim.

I can guess what Tom's going to say, since I argued your position
approx. 3 years ago. Implicitly committing transactions would not allow
for rollback of DDL statements. This is a great feature that PostgreSQL
has striven for that Oracle lacks. 3 years ago, it seemed to be a
problem, when a table created in an aborted transaction was not being
correctly cleaned up. It gets in the way of implementing an ALTER TABLE
DROP COLUMN easily, since rollback of a dropped column means that the
underlying data must be preserved. However, the developers have made
such great progress in properly rolling back DDL statements that it
would be a real shame to lose such a great feature. Additionally, it
could seriously break a lot of applications out there that do not
expect:

INSERT INTO foo VALUES (1);
CREATE TABLE bar (key integer);
ROLLBACK;

to fail to rollback the INSERT into foo. When the original discussion
came up, there were even a few of Oracle developers that didn't know
Oracle was committing their transactions behind their back.

Mike Mascari
mascarm@mascari.com