On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> That's more or less what I figured. One thing I'm uncomfortable with
>> is that, while this is useful for extensions, what do we do when we
>> have a similar requirement for core? The proposed GUC name is of the
>> format extension.user_defined_object_name.property_name; but omitting
>> the extension name would lead to
>> user_defined_object_name.property_name, which doesn't feel good as a
>> method for naming core GUCs. The user defined object name might just
>> so happen to be an extension name.
>
> I think that ship has long since sailed. postgresql.conf has allowed
> foo.bar style GUCs via custom_variable_classes for a long time, and
> these days we don't even require that but allow them generally. Also,
> SET, postgres -c, and SELECT set_config() already don't have the
> restriction to one dot in the variable name.
Well, we should make it consistent, but I'm not sure that settles the
question of which direction to go.
>> If it's not a good fit for pg_hba.conf, why is it a good fit for
>> anything else we want to do?
>
> Well, for now it's primarily there for extensions, not for core
> code. Although somebody has already asked when I'd submit the patch
> because they could use it for their patch...
> I don't really find the pg_hba.conf comparison terribly convincing. As
> an extension, how would you prefer to formulate the configuration
> in the example?
Well, to me it looks like what you've got there is a table. And I
don't have a clear feeling of how that ought to be represented in
configuration-land, but trying to jam it into the GUC machinery seems
awkward at best. I think we need a way of handling tabular
configuration data, but I'm not convinced this is it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
