2017-01-02 16:55 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > 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.
reset can means "set to default" 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. Regards Pavel > > > -- > Fabien. >
