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.1701021613480.26374@lancre
Whole thread Raw
In response to proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
>>> Attention! rollback is significantly expensive than RESET.
>>
>> I'm quite unclear about the difference... Transactional for an unshared 
>> only-in-memory session object is probably easy to implement, no WAL is 
>> needed... So I do not see the difference

> you have to store previous value

This does not fully answer my question.

Maybe RESET would put NULL instead of the previous value in a rollback?

If so, I must admit that I do not see any fundamental issue with holding 
temporarily the initial value of an in-memory session variables so as to 
be able to rool it back if required...

>>> There are no any product where variables are transactional - we should 
>>> not to create wheel.
>>
>> Well, AFAICS PostgreSQL GUCs are transactional.

> that is exception ..

That is just logic: if you make an argument based on "it does not exist", 
then the argument is void if someone produces a counter example.

> show me some transactiinal variables from msql, oracle, db2

I do not really know these three particular products. All I can say is 
that from a semantical point of view the contents of any one-row temporary 
relation is somehow a transactional session variable. However I do not 
know whether the 3 cited products have temporary tables, this is just a 
guess.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] Replication slot xmin is not reset if HS feedback isturned off while standby is shut down
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables