Hi Robert, On 2013-10-03 14:39:46 -0400, Robert Haas wrote: > On Mon, Sep 23, 2013 at 9:36 AM, Alvaro Herrera > <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
