Re: [RFC] Extend namespace of valid guc names - Mailing list pgsql-hackers

Hi Robert,

On 2013-10-03 14:39:46 -0400, Robert Haas wrote:
> On Mon, Sep 23, 2013 at 9:36 AM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > I think the idea that we should consider a different way of handling
> > tabular configuration data has merit.  In fact, how much sense does it
> > make to have these options (the ones for which this patch is being
> > written) be GUCs in the first place?  ALTER USER/DATABASE don't work for
> > them, they can't be usefully changed in the commandline, there's no
> > working SET.
> >
> > If we had some way to plug these into pg_hba.conf parsing machinery
> > (which is tabular data), I would suggest that.  But that doesn't sound
> > really sensible.  I think the idea of putting this configuratio data
> > in a separate file, and perhaps a more convenient format than
> > three-level GUC options, should be considered.
> 
> All very good points, IMHO.  In a lot of cases, what you want is
> 
> sneazle.list='foo,bar'
> sneazle.foo.prop1='zatz'
> sneazle.bar.prop1='frotz'
> etc.
> 
> But that means that the set of GUCs that exist to be SET needs to
> change every time sneazle.list changes, and we haven't got any good
> mechanism for that.

It'd be pretty easy to have a function that removes everything inside a
certain namespace. That'd be enough to make EmitWarningsOnPlaceholders()
work, right?

>  I really think we're trying to squeeze a square
> peg into a round hole here, and I accordingly propose to mark this
> patch rejected.

> It seems to me that if an extension wants to read and parse a
> configuration file in $PGDATA, it doesn't need any special core
> support for that.  If there's enough consistency in terms of what
> those configuration files look like across various extensions, we
> might choose to provide a set of common tools in core to help parse
> them.  But I'm not too convinced any useful pattern will emerge.

The problem is that such configuration formats needs to deal with a host
of already solved things like:
* triggering reload across backends
* presentation layer: SHOW/pg_settings
* The ability to override settings on certain levels: SET/ALTER DATABASE/ALTER ...
* Correct handling of invalid values on reload and such
* parsed early enough to allocate shared memory

That's quite the truckload of things that need to be done by any new
format.

I don't really understand the resistance to the patch. It's a two line
change that doesn't allow anything that wasn't already allowed by other
means (SET, SELECT set_config(), -c). It sure isn't perfect for
everything but for some scenarios it improves the scenario sufficiently
that it'd make at least one extension author happy ;)

> Another option is to store the data in an actual table.  One could
> have sneazle.configtable='dbname.schemaname.tablename', for example.

Doesn't really work if your extension needs to do stuff during startup
tho.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services