Re: [HACKERS] SAVEPOINT SQL conformance
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 contrast, RELEASE SAVEPOINT explicitly says that it destroys the specified savepoint and all savepoints established since the specified savepoint. If you converted the second SAVEPOINT a into RELEASE SAVEPOINT a; SAVEPOINT a then savepoint b would be incorrectly destroyed. You are right, that proves my proposal to be incorrect, because an implicit RELEASE SAVEPOINT a; has side effects that are definitively against the standard or what you would expect. Best Regards, Michael Paesold ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SAVEPOINT SQL conformance
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 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. On the other hand, we do have provisions in the code for savepoint naming levels, and so maybe a better answer to the collision issue is to support savepoint levels more completely. (But that's not standard either.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] SAVEPOINT SQL conformance
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 ... While that's true in this particular case, you can't do that transformation in the general case. Consider: 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 contrast, RELEASE SAVEPOINT explicitly says that it destroys the specified savepoint and all savepoints established since the specified savepoint. If you converted the second SAVEPOINT a into RELEASE SAVEPOINT a; SAVEPOINT a then savepoint b would be incorrectly destroyed. It'd work for the (common?) case where there are no intervening savepoints, though. -O ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SAVEPOINT SQL conformance
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 wrong, but I think the problem of name collision exists anyway, at least to some extent. The current behaviour will help in this case: BEGIN; ... SAVEPOINT a; SELECT func(); ... COMMIT; where func does: SAVEPOINT a; RELEASE or ROLLBACK TO a; But it will not help, if func only does: SAVEPOINT a; on error ROLLBACK TO a; (but no release path) Then, if an error occurs after the function call, an the programm executes ROLLBACK TO a; it will rollback to a state that existed inside the function... rather bad again. And... in PL/pgSQL you will use EXCEPTION blocks rather than SAVEPOINT directly... will there are still the other languages. I just wanted to show that it is still not _that_ save to use colliding savepoint names. Regards, Michael Paesold ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
