Re: SAVEPOINT SQL conformance
От | Michael Paesold |
---|---|
Тема | Re: SAVEPOINT SQL conformance |
Дата | |
Msg-id | 006501c49dc9$02858a70$d604460a@zaphod обсуждение исходный текст |
Ответ на | SAVEPOINT SQL conformance ("Michael Paesold" <mpaesold@gmx.at>) |
Список | 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 по дате отправления: