On 2013-09-19 14:57:53 -0400, Robert Haas wrote:
> On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > 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.
I suggested making it consistent in either form elsewhere in this
thread, Tom wasn't convinced. I think because of backward compatibility
concerns we hardly can restrict the valid namespace in all forms to the
most restrictive form (i.e. guc-file.l). Quite some people use GUCs as
variables.
Maybe we can forbid the more absurd variants (SET "..."."..." = 3;
SELECT set_config('...', '1', true)), but restricting it entirely seems
to cause pain for no reason.
> >> 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.
Well, it has two major advantages from my pov: a) we already have it
from SQL and people already use it that way b) it's dirt simple and it
doesn't allow anything not allowed before via other means.
Maybe you can invent something nicer to look at that's also parsed
before the server starts, but I find it hard to see the need
TBH. Especially as you will want most of the infrastructure GUCs
provide...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services