Re: Vote totals for SET in aborted transaction - Mailing list pgsql-hackers

On Mon, 2002-04-29 at 17:53, 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?

should be baz

I'm elaborating the idea of SET with transaction scope here with
possibility to do global SETs as well. Any global SET will also affect
local set (by either setting it or just unsetting the local one).

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

baz again, as local foo==quux disappears at transaction 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?

baz

I assume here only two kinds of SETs - global ones that happen always
and local ones that are valid only within the transaction

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

I started from the idea of not rolling back SETs as they do not affect
data but I think that transaction-local SETs are valuable.

If we go with your syntax I would prefer SET LOCAL to LOCAL SET , so
that LOCAL feels tied more to variable rather than to SET .

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

It is always GLOBAL unless SET TO LOCAL

I explicitly defined this command as applying to itself and all
following commands in order to avoid this circularity so END would
invalidate it

But I already think that LOCAL SET / SET LOCAL is better and more clear.

> And if you say LOCAL,
> how do you justify it?  Why wouldn't the effects of this SET be local?

------------
Hannu