On Fri, Oct 4, 2013 at 6:06 AM, Andres Freund <and...@2ndquadrant.com> wrote: > 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?
Maybe, but I don't think you're going to paper over the problem that easily. The GUC mechanism just isn't decided to support settings that pop into and out of existence like that. It's not a coincidence that there's no UNSET commands for GUCs. We have RESET but that means "go back to the default", not "go away". You're trying to bend the mechanism to do something that it fundamentally wasn't designed to do. I don't think that's the right way to go, but if we do decide to go in that direction it's going to take more than a trivial patch to get there. > 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. True. > 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 ;) That's true, but I think the fact that those things work is an oversight rather than a deliberate design decision. >> 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. Granted. There's not a perfect mechanism here. But I think we should be devoting some thought to what a good mechanism that could be used by core *and* contrib would look like, rather than thinking that a quick hack is going to make the pain go away. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
