Re: [RFC] Extend namespace of valid guc names
От | Andres Freund |
---|---|
Тема | Re: [RFC] Extend namespace of valid guc names |
Дата | |
Msg-id | 20131004141438.GQ19661@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: [RFC] Extend namespace of valid guc names (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [RFC] Extend namespace of valid guc names
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
On 2013-10-04 09:57:41 -0400, Robert Haas wrote: > On Fri, Oct 4, 2013 at 6:06 AM, Andres Freund <andres@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. But that's not a new problem? It already exists and isn't really excerbated by this. > > 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. Yes, but it's already being used, so, while some minor restrictions probably aren't to problematic, forbidding multiple dots outright seems like unnecessarily breaking user applications. > >> 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. I agree that we could use some more infrastructure around configuration, but I fail to understand why it's this patch's duty to deliver it. And I don't see why this patch would endanger any more groundbreaking improvements. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: