Re: Vote totals for SET in aborted transaction - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Vote totals for SET in aborted transaction
Date
Msg-id 25960.1019831678@sss.pgh.pa.us
Whole thread Raw
In response to Re: Vote totals for SET in aborted transaction  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Responses 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>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_constraint
Next
From: Tom Lane
Date:
Subject: Re: WAL -> Replication