Re: proposal: session server side variables

2017-01-03 18:52 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> ****** PLEASE ******
>>> COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN
>>> REPLYING IN THE THREAD?
>>> ****** THANKS ******
>>
>>
> Hmmm. It seems that you can't. You should, really.

I am sorry - The gmail client mask me these parts. I'll clean it more

>
>
> If you use patterns that I wrote - the security context will be valid
>>>> always.
>>>>
>>>
>>> No: This pattern assumes that operations started in the "TRY" zone
>>> cannot fail later on... This assumption is false because of possible
>>> deferred triggers for instance. See attached example:
>>>
>>
>> ok .. it is pretty artificial, but ok.
>>
>
> Good. We seem to agree that some kind of transactional support is needed
> for the use case, which is pretty logical.
>
> In this case the reset to NULL on ROLLBACK should be enough.
>>
>
> Probably.
>
> So I expect that you are going to update your proposal somehow to provide
> some transactional properties.
>
> Note that if you have some mecanism for doing a NULL on rollback, then why
> not just keep and reset the previous value if needed? This just means that
> you have a transactional variable, which is fine from my point of view. As
> I already wrote, session variable are memory only, so transactional does
> not involve costs such as WAL.
>

There is not cost such as WAL - in any update, you have to check if this is
first update in transaction, and if it is, then you have to create new
memory context and create new callback that will be evaluated on rollback.

Probably there is not big difference between RESET and UNDO in complexity
of implementation. You have to do partial implementation of MVCC. No simple
code.

>
> Also note that user-defined GUCs already implements the transactional
> property, so probably the mecanism is already available and can be reused.

GUC are stack based - the value doesn't depends if transaction was
successful or not.

> --
> Fabien.
>