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.
