Re: Vote totals for SET in aborted transaction

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: Vote totals for SET in aborted transaction
Дата
Msg-id 1020098478.27494.23.camel@taru.tm.ee
обсуждение исходный текст
Ответ на Re: Vote totals for SET in aborted transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Vote totals for SET in aborted transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, 2002-04-29 at 17:30, Tom Lane wrote:
> Scott Marlowe <scott.marlowe@ihs.com> writes:
> > I've been thinking this over and over, and it seems to me, that the way 
> > SETS in transactions SHOULD work is that they are all rolled back, period, 
> > whether the transaction successfully completes OR NOT.
> 
> This would make it impossible for SET to have any persistent effect
> at all.  (Every SQL command is inside a transaction --- an
> implicitly-established one if necesary, but there is one.)
> 
> It might well be useful to have some kind of LOCAL SET command that
> behaves the way you describe (effects good only for current transaction
> block), but I don't think it follows that that should be the only
> behavior available.
> 
> What would you expect if LOCAL SET were followed by SET on the same
> variable in the same transaction?  Presumably the LOCAL SET would then
> be nullified; or is this an error condition?

Perhaps we could do 

SET SET TO LOCAL TO TRANSACTION;

Which would affect itself and all subsequent SET commands up to 

SET SET TO GLOBAL;

or end of transaction.

-------------

SET SET TO GLOBAL 

could also be written as 

SET SET TO NOT LOCAL TO TRANSACTION;

to comply with genral verbosity of SQL ;)

----------
Hannu




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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Vote totals for SET in aborted transaction
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: Vote totals for SET in aborted transaction