Re: proposal: session server side variables

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
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 20:06:10
Message-ID: CAFj8pRAW2OudNy_NECDxZUjn9Jpvqss6t1c6Un-cTi=rg1JX7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2017-01-03 20:56 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> 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'
> SELECT set_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...

With respect, I don't share your opinion - it is not enough for usage like
package variables - there usually should not to use any dependency on
transactions.

More it is dynamic - it should be hard inconsistency to implement CREATE or
DECLARE statement for GUC. So it is out my proposal (and my goal).

Regards

Pavel

>
>
> --
> Fabien.
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2017-01-03 20:15:45 Re: merging some features from plpgsql2 project
Previous Message Justin Pryzby 2017-01-03 19:57:09 Re: ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type