Re: proposal: schema variables

st 20. 11. 2024 v 15:15 odesílatel Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>
napsal:

> Em qua., 20 de nov. de 2024 às 10:52, Pavel Stehule <
> pavel(dot)stehule(at)gmail(dot)com> escreveu:
>
>> COMMIT can be a little bit messy. TRANSACTION END is more intuitive, I
>> think.
>>
>>>
> Exactly to be not messy I would just ON COMMIT for all, and DOCs can
> explain that this option is ignored for temp objects and do the same at the
> end of transaction, independently if commited or rolled back
>

I feel it differently - when I read ON COMMIT, then I expect really just a
COMMIT event, not ROLLBACK. Attention - the metadata about variables are
transactional, but the variables are not transactional (by default).

But this feeling can be subjective. The objective argument against using ON
COMMIT like ON TRANSACTION END is fact, so we lost a possibility for a more
precious setting.

I can imagine scenarios with ON COMMIT RESET - and variable can hold some
last value from transaction, or ON ROLLBACK RESET - and variable can hold
some computed value from successfully ended transaction - last inserted id.

In this case, I don't see a problem to reopen a discussion about syntax or
postpone this feature. I think the possibility to reset variables at some
specified time can be an interesting feature (that can increase safety,
because the application doesn't need to solve initial setup), but from the
list of implemented features for session variables, this is not too far
from the end. If TRANSACTION END is not intuitive - with exactly the same
functionality can be RESET AT TRANSACTION START - so the ON TRANSACTION END
can be transformed to ON BEGIN RESET, and this syntax can be maybe better,
because it signalize, for every transaction, the variable will be
initialized to default. What do you think? Can be ON BEGIN RESET acceptable
for you.

Regards

Pavel