Re: Vote totals for SET in aborted transaction

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