Re: [HACKERS] 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.