Hello Bruce,

Good. So we seem to agree that GUCS are transactional?

Uh, I think it is a missing feature, i.e.:

        Have custom variables be transaction-safe

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


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to