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

Re: Vote totals for SET in aborted transaction

From: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>,Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote totals for SET in aborted transaction
Date: 2002-04-29 18:10:13
Message-ID: 20020429150943.R15173-100000@mail1.hub.org (view raw or flat)
Thread:
Lists: pgsql-hackers
What happens inside of a nested transaction, assuming we do have those
evenually ... ?

On Mon, 29 Apr 2002, Tom Lane wrote:

> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > Perhaps we could do
> > SET SET TO LOCAL TO TRANSACTION;
> > Which would affect itself and all subsequent SET commands up to
> > SET SET TO GLOBAL;
> > or end of transaction.
>
> This makes my head hurt.  If I do
>
> 	SET foo TO bar;
> 	begin;
> 	SET SET TO GLOBAL;
> 	SET foo TO baz;
> 	SET SET TO LOCAL TO TRANSACTION;
> 	end;
>
> (assume no errors) what is the post-transaction state of foo?
>
> What about this case?
>
> 	SET foo TO bar;
> 	begin;
> 	SET SET TO GLOBAL;
> 	SET foo TO baz;
> 	SET SET TO LOCAL TO TRANSACTION;
> 	SET foo TO quux;
> 	end;
>
> Of course this last case also exists with my idea of a LOCAL SET
> command,
>
> 	SET foo TO bar;
> 	begin;
> 	SET foo TO baz;
> 	LOCAL SET foo TO quux;
> 	-- presumably SHOW foo will show quux here
> 	end;
> 	-- does SHOW foo now show bar, or baz?
>
> Arguably you'd need to keep track of up to three values of a SET
> variable to make this work --- the permanent (pre-transaction) value,
> to roll back to if error; the SET value, which will become permanent
> if we commit; and the LOCAL SET value, which may mask the pending
> permanent value.  This seems needlessly complex though.  Could we get
> away with treating the above case as an error?
>
> In any case I find a LOCAL SET command more reasonable than making
> SET's effects depend on the value of a SETtable setting.  There is
> circular logic there.  If I do
>
> 	begin;
> 	SET SET TO LOCAL TO TRANSACTION;
> 	end;
>
> what is the post-transaction behavior of SET?  And if you say LOCAL,
> how do you justify it?  Why wouldn't the effects of this SET be local?
>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>


In response to

Responses

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2002-04-29 18:13:44
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: Tom LaneDate: 2002-04-29 18:05:39
Subject: Folding variable.c into the GUC structure, redux

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