Re: Vote totals for SET in aborted transaction

Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)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