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

Re: Vote totals for SET in aborted transaction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
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 14:34:38
Message-ID: 25960.1019831678@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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
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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-04-26 14:41:02
Subject: Re: WAL -> Replication
Previous:From: Tom LaneDate: 2002-04-26 14:25:12
Subject: Re: pg_constraint

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