Hi,
On Wed, Jan 26, 2022 at 02:43:54PM +0100, Pavel Stehule wrote:
>
> I think this is still necessary. The lock protects the variable against
> drop from the second session, but not for reverted deletion from the
> current session.
>
> This implementation is due Tomas's request for
>
> CREATE VARIABLE xx AS int;
> LET xx = 100;
> BEGIN;
> DROP VARIABLE xx;
> ROLLBACK;
> SELECT xx; --> 100
>
> and the variable still holds the last value before DROP
I thought about this case, but assumed that the own session wouldn't process
the inval until commit. Agreed then, although the comment should clarify the
transactional behavior and why it's still necessary.
> Personally, this is a corner case (for me, and I think so for users it is
> not too interesting, and important), and this behavior is not necessary -
> originally I implemented just the RESET variable in this case. On the other
> hand, this is a nice feature, and there is an analogy with TRUNCATE
> behavior.
>
> More, I promised, as a second step, implementation of optional
> transactional behavior of session variables. And related code is necessary
> for it. So I prefer to use related code without change.
That's another good reason, so fine by me!