Horton

Re: Vote totals for SET in aborted transaction

Lincoln Yeoh <lyeoh@pop.jaring.my>

View thread View on postgr.es
From: Lincoln Yeoh <lyeoh@pop.jaring.my>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Marc G. Fournier" <scrappy@hub.org>, Bruce Momjian <pgman@candle.pha.pa.us>, Mike Mascari <mascarm@mascari.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2002-04-27T00:12:23Z
Lists: pgsql-hackers 
At 11:49 AM 4/26/02 -0400, Tom Lane wrote:
>I'm still looking for an example of something that is (a) reasonable
>to set on a per-backend basis, and (b) not reasonable to roll back
>if it's set in a transaction that fails.

The way I see it is if (a) and you don't want it rolled back, you could put 
it in a transaction of its own.
BEGIN;
SET backend pref;
COMMIT;

And if that transaction fails, maybe it should :).

So other than for performance, the example should also have a reason to 
belong with other statements in a transaction.

Have a nice weekend,
Link.