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...
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
