Re: Vote totals for SET in aborted transaction

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

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