Re: Vote totals for SET in aborted transaction

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)
>