Mark Dilger <mark.dil...@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 be present in the catalog, but in
> fact, not entering them in the catalog simply means that they aren't
> grantable. I think the confusion arose from the fact that I created a
> mechanism for extension authors to enter additional gucs into the catalog,
> which gave the false impression that such entries were required. They are
> not. I didn't bother explaining that before, 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
