Re: [RFC] Extend namespace of valid guc names

On Fri, Oct 4, 2013 at 6:06 AM, Andres Freund <andres(at)2ndquadrant(dot)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