Re: proposal: session server side variables

2017-01-02 16:55 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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.
>