Re: Vote totals for SET in aborted transaction

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Vote totals for SET in aborted transaction
Дата
Msg-id 25960.1019831678@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  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Vote totals for SET in aborted transaction  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Список pgsql-hackers
Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
> Coz some things should not be rolled back. So you guys might come up with a 
> different keyword for it.

> CONFIG: for non transactional stuff that can appear as SQL statements.
> SET: for stuff that can be transactional.

People keep suggesting this, and I keep asking for a concrete example
where non-rollback is needed, and I keep not getting one.  I can't see
the value of investing work in creating an alternative behavior when
we have no solid example to justify it.

The "Oracle compatibility" argument would have some weight if we were
making any concerted effort to be Oracle-compatible across the board;
but I have not detected any enthusiasm for that.  Given that it's not
even the same syntax ("SET ..." vs "ALTER SESSION ...") I'm not sure
why an Oracle user would expect it to behave exactly the same.

> Practical example: Does doing an enable seqscan affect OTHER db connections 
> and transactions as well?

There are no SET commands that affect other backends.  (There are
GUC variables with system-wide effects, but we don't allow them to be
changed by SET; rollback or not won't affect that.)
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_constraint
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WAL -> Replication