On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers