Re: SAVEPOINT SQL conformance - Mailing list pgsql-hackers

From Michael Paesold
Subject Re: SAVEPOINT SQL conformance
Date
Msg-id 006501c49dc9$02858a70$d604460a@zaphod
Whole thread Raw
In response to SAVEPOINT SQL conformance  ("Michael Paesold" <mpaesold@gmx.at>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: SAVEPOINT SQL conformance
Next
From: Mahmoud Taghizadeh
Date:
Subject: How to add locale support for each column?