Re: [spf:guess] Re: ROLLBACK TO SAVEPOINT

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: [spf:guess] Re: ROLLBACK TO SAVEPOINT
Дата
Msg-id 4BFDA77E.6030302@enterprisedb.com
обсуждение исходный текст
Ответ на Re: [spf:guess] Re: ROLLBACK TO SAVEPOINT  (Sam Vilain <sam@vilain.net>)
Ответы Re: [spf:guess] Re: ROLLBACK TO SAVEPOINT  (Florian Pflug <fgp@phlo.org>)
Список pgsql-hackers
On 26/05/10 02:00, Sam Vilain wrote:
> Florian Pflug wrote:
>> On May 25, 2010, at 12:18 , Heikki Linnakangas wrote:
>>> Releasing the newer savepoint will cause the older one to again become accessible, as the doc says, but rolling
backto a savepoint does not implicitly release it. You'll have to use RELEASE SAVEPOINT for that.
 
>>
>> Ah, now I get it. Thanks.
>>
>> Would changing "Releasing the newer savepoint will cause ... " to "Explicitly releasing the newer savepoint" or
maybeeven "Explicitly releasing the newer savepoint with RELEASE SAVEPOINT will cause ..." make things clearer?
 
>
> Yes, probably - your misreading matches my misreading of it :-)

+1.

> There is another way you can get there - releasing to a savepoint before
> the re-used savepoint name will also release the savepoints after it.
>
> ie
>
>     savepoint foo;
>     savepoint bar;
>     savepoint foo;
>     release to savepoint bar;
>     release to savepoint foo;
>
> After the first release, the second 'foo' savepoint is gone.  I think
> this is a key advantage in saving the old savepoints.

Yep. Do we need to mention that in that notice? I don't think so, it 
would become really verbose. Florian's wording above seems fine.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: functional call named notation clashes with SQL feature
Следующее
От: Greg Stark
Дата:
Сообщение: Re: primary/secondary/master/slave/standby