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@tm.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@postgresql.org)
>