Hi,
On 2013-09-17 16:24:34 -0400, Robert Haas wrote:
> 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:
> >> 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.
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.
I think if we're going to use something like that for postgres, we'll
have to live with the chance of breaking applications (although I don't
think it's that big for most of the variables where I can forsee the use).
> 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?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
