Hello Bruce,
Good. So we seem to agree that GUCS are transactional?
Uh, I think it is a missing feature, i.e.:
https://wiki.postgresql.org/wiki/Todo#Administration
Have custom variables be transaction-safe
https://www.postgresql.org/message-id/4b577e9f.8000...@dunslane.net
Hmmm, that is a subtle one:-)
After more testing, the current status is that the values of existing
user-defined parameters is cleanly transactional, as already tested:
fabien=# SET x.x = 'before';
fabien=# BEGIN;
fabien=# SET x.x = 'inside';
fabien=# ROLLBACK;
fabien=# SHOW x.x;
-- 'before'
This is what I meant by "GUCs are transactional".
However, as you point out, the existence of the parameter is not: If it is
created within an aborted transaction then it still exists afterwards:
fabien=# SHOW z.z;
ERROR: unrecognized configuration parameter "z.z"
fabien=# BEGIN;
fabien=# SET z.z = 'yep';
fabien=# ROLLBACK;
fabien=# SHOW z.z;
-- no error, empty string shown
So GUCs are... half-transactional? :-)
From the security-related use case perspective, this half transactionality
is enough, but it is not very clean. Does not look like a very big issue
to fix, it just seems that nobody bothered in the last 6 years...
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
