Hello,
In my proposal was support for transaction scope - ON COMMIT RESET
clause should be ok
Could you update the wiki, both the proposal and the use-case
implementation, to reflect this point?
Moreover, is there any actual use-case for non-transactional secure
half-persistent session variables? AFAICS the "secure" part implies both
permissions and transactional for the presented security-related use case.
If there is no use case for these combined features, then ISTM that you
should update to proposal so that the variables are always transactional,
which is both simpler, more consistent, and I think more acceptable.
If you are transaction sensitive, then you have to be sensitive to
subtransactions - then the work is much more complex.
Maybe, probably, I do not really know. For now, I'm trying to determine
how the proposals fits Craig's use case.
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.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
