Re: proposal: session server side variables

Hello Pavel,

PLEASE, could you remove the parts of emails you are not responding to
when replying in the thread? THANKS.

>>>> The current status is that both proposals are useless because the use
>>>> case needs "some" transactional property for security. But probably
>>>> some improvements are possible.
>>>
>>> Is there use case, when you would to play with transactions and
>>> variables and RESET is not enough?
>>
>> I do not know. If you explain more clearly what is meant by a "RESET" on a
>> variable when the transaction fails, then maybe I can have an opinion.
>> Currently I'm just guessing in the dark the precise intended semantics.
>
> reset can means "set to default"

"can"? The question is what does it mean in your proposal, not what it may
mean. So I understand that it means "variable always reset to its default
value at the end of the transaction".

> Now when I though about it - this scenario is not interesting for PL -
> probably can be interesting for some interactive work. In PL you can
> handle transactions - so you know if was or was not any exceptions. And
> if you didn't handle the exception, then you are in "need rollback
> state", so you cannot to anything - look on variable value too. In PL is
> usually important transaction start - difficult question if it can means
> subtransaction start too.

What I understand from this use case variation is that the secure variable
is expected to be set & used only *within* a single transaction, although
across multiple functions typically called from some server-side
PL-script, so that its value outside of the transaction does not matter
wrt to security concerns. Did I understand?

For this use-case, ISTM that the scope of the variable is necessarily the
transaction, not the session, i.e. like using "set_config(..., TRUE)".

--
Fabien.