Re: Vote totals for SET in aborted transaction

At 10:34 AM 4/26/02 -0400, Tom Lane wrote:
>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

Sorry, I wasn't clear enough. I'm not asking for non-rollback behaviour.

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.

> > 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.)

OK.

Cheerio,
Link