From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: session server side variables |
Date: | 2017-01-02 15:32:47 |
Message-ID: | alpine.DEB.2.20.1701021613480.26374@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-01-02 15:55:49 | Re: proposal: session server side variables |
Previous Message | Craig Ringer | 2017-01-02 14:24:45 | Re: Replication slot xmin is not reset if HS feedback is turned off while standby is shut down |