I'm working again on the patch for making guc variables fall back to their
default value if they get removed (or commented) in the configuration file.
There is still an issue with custom variables that needs discussion.
Remember that for regular variables we have the following semantics:
BEGIN;
SET enable_seqscan TO off;
COMMIT;
The effect of the commit on the variable is that the variable is set to the
specified value from then on in that session (outside of the transaction).
This is also valid for custom variables. But those can be removed from the
configuration file while all other variables can not (all other variables
fall back to some default value).
Imagine the following example:
Configuration file:custom_variable_classes = "foo"foo.var = 3
In a session we do:BEGIN;SET foo.var TO 5;
With the transaction still being open, we remove the definition of foo.var
from the configuration file and send SIGHUP.
Then we commit the transaction:
COMMIT;
So what should happen?
Interpretation 1:foo.var got deleted. COMMIT can not assure that the value offoo.var gets applied, because foo.var does
notexist anymore.The transaction fails.
Interpretation 2:The foo.var variable from the configuration file got deleted but theSET command in the transaction
definesa new variable which isvalid, because we still have custom_variable_classes = "foo". Thetransaction succeeds.
The second interpretation is based on the fact that you can create a custom
variable by just assigning a value to it. So if you have
custom_variable_classes = "foo", foo.<anythinghere> is a valid variable.
Actually I think we could go either way, it seems to be a really rare corner
case. I'm fine with either way.
Note that if we deleted the line with "custom_variable_classes = foo" from
the previous example as well, it is clear that the transaction should fail.
Joachim