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 savepo
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
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 ...
"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 fa
