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