On Tue, Sep 17, 2013 at 10:27 AM, Andres Freund <andres@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 <andres@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