Re: Vote totals for SET in aborted transaction

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Vote totals for SET in aborted transaction
Дата
Msg-id 26599.1019836159@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Vote totals for SET in aborted transaction  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Ответы Re: Vote totals for SET in aborted transaction  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Список pgsql-hackers
Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
> I was trying to say that _IF_ one ever needs to "SET" stuff that can't be 
> rolled back then it may be better to use some other keyword for that feature.
> I'm actually for #1 SET being rolled back and to not have any "Oracle 
> behaviour" settings at all. Anything that can't be rolled back shouldn't 
> use SET.

Ah, I understand.  Okay, I see a perfect candidate for the other syntax:
ALTER SESSION SET ...

(or whatever the heck that Oracle syntax was).  But I'm still looking
for a case of a variable where we actually want this behavior.

The Ingres examples Lee cited were interesting --- but they all appear
to me to correspond to system-wide settings, which we do not allow SET
to modify anyway.  (To change system-wide settings, you have to change
postgresql.conf, and then SIGHUP or restart the postmaster.  This
ensures all the backends get the word.  And indeed this behavior is
outside transactional control.)

I'm still looking for an example of something that is (a) reasonable
to set on a per-backend basis, and (b) not reasonable to roll back
if it's set in a transaction that fails.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_constraint
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: Vote totals for SET in aborted transaction