Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id alpine.DEB.2.20.1701031839280.3802@lancre
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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.



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] merging some features from plpgsql2 project
Next
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Update copyright for 2017