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