From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com> |
Subject: | Re: proposal: session server side variables |
Date: | 2017-01-03 17:52:34 |
Message-ID: | alpine.DEB.2.20.1701031839280.3802@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> ****** 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.
>>> 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.
Also note that user-defined GUCs already implements the transactional
property, so probably the mecanism is already available and can be reused.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2017-01-03 17:54:37 | Re: pgsql: Update copyright for 2017 |
Previous Message | Pavel Stehule | 2017-01-03 17:51:55 | Re: merging some features from plpgsql2 project |