Mark Dilger <mark.dilger@enterprisedb.com> writes:
> The patch already posted on this thread already works that way. Robert and Tom seemed to infer that all gucs need to
bepresent in the catalog, but in fact, not entering them in the catalog simply means that they aren't grantable. I
thinkthe confusion arose from the fact that I created a mechanism for extension authors to enter additional gucs into
thecatalog, which gave the false impression that such entries were required. They are not. I didn't bother explaining
thatbefore, because Robert and Tom both seem to expect all gucs to be grantable, an expectation you do not appear to
share.
The question is why you need pg_config_param at all, then.
AFAICS it just adds maintenance complexity we could do without.
I think we'd be better off with a catalog modeled on the design of
pg_db_role_setting, which would have entries for roles and lists
of GUC names that those roles could set.
BTW, another objection to pg_config_param as designed here is that
a "name" is not an appropriate way to store possibly-qualified
custom GUC names. It's not long enough (cf. valid_custom_variable_name).
>> To support pg_dump and pg_upgrade, it might be better to have an
>> enabled/disabled flag rather than to delete rows.
> I'm not really sure what this means.
I didn't see the point of this either. We really need to KISS here.
Every bit of added complexity in the catalog representation is another
opportunity for bugs-of-omission, not to mention a detail that you
have to provide mechanisms to dump and restore.
regards, tom lane
