Skip site navigation (1) Skip section navigation (2)

Re: Vote totals for SET in aborted transaction

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Mike Mascari <mascarm(at)mascari(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote totals for SET in aborted transaction
Date: 2002-04-26 15:35:36
Message-ID: 5.1.0.14.1.20020426231925.0302c0e0@192.228.128.13 (view raw or flat)
Thread:
Lists: pgsql-hackers
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



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-04-26 15:44:29
Subject: Re: pg_constraint
Previous:From: Tom LaneDate: 2002-04-26 15:20:52
Subject: Re: Vote totals for SET in aborted transaction

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group