Re: [HACKERS] SAVEPOINT SQL conformance

2004-09-19 Thread Michael Paesold
Oliver Jowett wrote: BEGIN SAVEPOINT a -- work SAVEPOINT b -- work SAVEPOINT a -- work ROLLBACK TO b -- work This is valid: the standard says that the second SAVEPOINT a destroys and recreates the savepoint a, but doesn't say that it destroys intervening savepoints. In

Re: [HACKERS] SAVEPOINT SQL conformance

2004-09-18 Thread Tom Lane
Michael Paesold [EMAIL PROTECTED] writes: If the first example code is used (which I would use if I did not think about postgresql's exception), the subxact state stack in xact.c will grow and grow and grow... whereas in the case of compliance with the standard, it will not. This is fairly

Re: [HACKERS] SAVEPOINT SQL conformance

2004-09-18 Thread Oliver Jowett
Michael Paesold wrote: BEGIN; SAVEPOINT a; INSERT INTO ... SAVEPOINT a; INSERT INTO ... SAVEPOINT a; ... (encountering an error it would just ROLLBACK TO a;) According to the standard this is exactly the same as: BEGIN; SAVEPOINT a; INSERT INTO ... RELEASE SAVEPOINT a; SAVEPOINT a; INSERT INTO ...

Re: [HACKERS] SAVEPOINT SQL conformance

2004-09-18 Thread Michael Paesold
Tom Lane wrote: This is fairly irrelevant though, as the state stack entry is only a small part of the resources consumed by an uncommitted subtransaction. I don't really think it outweighs the argument you quoted about accidental collisions of savepoint names causing problems. Perhaps I am