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.