Re: [HACKERS] proposal: session server side variables
От | Pavel Stehule |
---|---|
Тема | Re: [HACKERS] proposal: session server side variables |
Дата | |
Msg-id | CAFj8pRAW2OudNy_NECDxZUjn9Jpvqss6t1c6Un-cTi=rg1JX7Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] proposal: session server side variables (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: [HACKERS] proposal: session server side variables
|
Список | pgsql-hackers |
2017-01-03 20:56 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.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.
В списке pgsql-hackers по дате отправления: