On Tue, Oct 30, 2012 at 5:25 PM, Josh Berkus <j...@agliodbs.com> wrote: > On 10/29/12 6:40 AM, Chris Corbyn wrote: >> What's the use case of this? It sounds like it will just create a >> maintenance nightmare where some stuff you expect to lookup in in >> postgresql.conf is actually hiding in the .auto file. Assuming only super >> users/sysadmins would have the ability to change things in the config file, >> wouldn't they be more likely to just do it on the server and edit the .conf >> (which among other things, keeps it tidy and orderly). > > The use is the ability to manage dozens, or hundreds, of PostgreSQL > servers via Port 5432. It would also make writing an auto-configurator > easier. > > I agree that there's not much benefit if you're only managing a single > PostgreSQL server. There's a lot of benefit for those of us who have to > manage a lot of them though.
I rather think that the fact that postgresql.conf has supported an "include directive" since at least as far back as 8.2 (likely further; I'll not bother spelunking further into the docs) makes this extremely troublesome. We have long supported the notion that this configuration does not have a Unique Place to be (e.g. - if you use INCLUDE, then there are at least two possible places). I should think that doing this requires heading back towards there being a single unique configuration stream, and over the course of several versions, deprecating the INCLUDE directive. I imagine it means we'd want to come up with a representation that has suitable semantics for being written to, make sure it is reasonably expressive *without* INCLUDE, and establish a migration path between the old and new forms. At some point, the old form can be treated as vestigal, and be dropped. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
