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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
