On Tue, Sep 17, 2013 at 10:27 AM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2013-09-17 10:23:30 -0400, Robert Haas wrote: >> On Sat, Sep 14, 2013 at 5:21 PM, Andres Freund <and...@2ndquadrant.com> >> wrote: >> >> a) allow repeatedly qualified names like a.b.c >> > >> > The attached patch does a) >> >> What is the use case for this change? > > Check > http://archives.postgresql.org/message-id/20130225213400.GF3849%40awork2.anarazel.de > or the commit message of the patch.
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. More generally, it seems like this is trying to take structured data and fit into the GUC mechanism, and I'm not sure that's going to be a real good fit. I mean, pg_hba.conf could be handled this way. You could have hba.1.type = local, hba.1.database = all, hba.1.user = all, hba.2.type = host, etc. But I doubt that any of us would consider that an improvement over the actual approach of having a separate file with that information. If it's not a good fit for pg_hba.conf, why is it a good fit for anything else we want to do? -- 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
