This an item in the TODO list. But I am not sure how severe the problem is.
In my understanding, there are not so many conflicts but we may want to give
some hints to users of how to set proper GUC variables. For instance, if we
find "debug_print_parse" is set, we will suggest setting
"debug_pretty_print" as well.
To support:
1. Prevent conflicting set options;
2. Suggest correct/better options;
We make two modifications:
1. Add a member to current config_pool structure
struct config_bool
{ struct config_generic gen; ... char* test_cond; /* Condition to be tested before the new value is
set */
};
Member test_cond saves a SQL command, which expresses the suggestions and
requirements of the setting.
2. Create a temp table pg_guc at the backend startup time. Each column of
this table is a guc variable. That is, the pg_guc will have the following
columns (debug_print_parse char(5), debug_pretty_print char(5), ...) - the
data type could be refined;
Now, we could define "test_cond" of debug_print_parse like this:
"SELECT CASE WHEN debug_pretty_print='true' THEN 'ok' ELSE CASE WHEN debug_print_parse='true' THEN 'You\'d
betterset
debug_pretty_print as well' -- otherwise, leave to assign_hook END END
AS result FROM pg_guc;"
When SET command is issued, PG will run test_cond as a SQL command, and
check the result. Of course, assign_hook will still be needed.
In this design, our ability to check the conflicting SET or give suggestions
is contributed by SQL's functionality. This is good I think. But there is
one thing: we can't execute a SQL command at any time. For example, at
server startup. Meanwhile, we will keep a redundant(to guc variables) temp
table to store these values, this is a kind of waste.
Regards,
Qingqing