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

From Lincoln Yeoh
Subject Re: Vote totals for SET in aborted transaction
Date
Msg-id 5.1.0.14.1.20020426231925.0302c0e0@192.228.128.13
Whole thread Raw
In response to Re: Vote totals for SET in aborted transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Vote totals for SET in aborted transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Vote totals for SET in aborted transaction
Next
From: Jan Wieck
Date:
Subject: Re: Vote totals for SET in aborted transaction