Re: [HACKERS] proposal: session server side variables

Hello,

> 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.

I think so; yes; indeed.

>> 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.

Hmmm... this looks transactional to me:
  SELECT set_config('x.x', 'before', FALSE); -- 'before'  BEGIN;    SELECT set_config('x.x', 'within', FALSE); --
'within' ROLLBACK;  SELECT current_setting('x.x'); -- 'before'  BEGIN;    SELECT set_config('x.x', 'inside', FALSE); --
'inside' COMMIT;  SELECT current_setting('x.x'); -- 'inside'
 

I would say the stack is needed for SAVEPOINT:
  SELECT set_config('x.x', 'before', FALSE); -- 'before'  BEGIN;    SELECT set_config('x.x', 'within', FALSE); --
'within'   SAVEPOINT within;    SELECT set_config('x.x', 'inside', FALSE); -- 'inside'    SELECT
current_setting('x.x');-- 'inside'    ROLLBACK TO SAVEPOINT within;    SELECT current_setting('x.x'); -- 'within'
SELECTset_config('x.x', 'further', FALSE); -- 'further'  ROLLBACK;  SELECT current_setting('x.x'); -- 'before'
 

So basically the use case needs GUCs with some access control. Or just 
role-private GUCs and some access function tricks would do as well for the 
use case. At least it is probably much easier to add privacy to gucs than 
to (re)implement permissions and MVCC on some session variables. And it 
would be nice if GUCs could be typed as well...

-- 
Fabien.