On Tue, Jul 30, 2013 at 6:40 PM, Josh Berkus <j...@agliodbs.com> wrote: > > On 07/30/2013 10:28 AM, Greg Stark wrote:> On Tue, Jul 30, 2013 at 6:10 > PM, Alvaro Herrera >> Well more to the point, if we conf.d for sysadmins to drop in extra >> snippets in a different place then we could drop conf.d in PGDATA >> since there's no need for it any more and just have auto.conf in >> PGDATA directly. > > That assumes that the only reason we have for a conf.d is to support > auto.conf, which I don't agree with; I personally have a need for conf.d > which has nothing to do with auto.conf.
No, wait. We had two reasons for conf.d and we thought we could kill two birds with one stone. It seems it's turning out that we can't kill both birds with the same stone because we want to separate the user maintained config from the automatically maintained config even further than just having them in separate files. Now we need them in separate directories. If you have a need for conf.d which has nothing to do with auto.conf then you presumably will want to be editing the system conf.d which might be in PGDATA or might be in /etc or might be someplace else. I totally agree that conf.d is useful for sysadmins as well as for distribution authors. But if we're going to insist that conf.d be in PGDATA then I'm saying we don't need a second conf.d just to contain that one file. And if we let distributions and sysadmins drop files in there then we'll be back to square 0 with wanting to separate them. I guess what I'm saying is that auto.conf shouldn't be in conf.d after all. It should just be in PGDATA directly and trying to kill two birds with one stone led us astray. Putting it in conf.d creates a raft of problems of what if conf.d is moved and what if it's shared between databases and what if the user puts files that come after it, etc. Putting it directly in PGDATA lets us manage those issues however we want and ties the automatic file to a specific database regardless of how we handle conf.d in the future. > Also, see gsmith's point about forcing auto.conf to be in PGDATA as not > satisfactory for Debian users (and others). Greg Smith's argument was about recovery.conf which is a file that users are expected to edit. A file which user's are not expected to edit and is maintained by the software is no more a configuration file than pg_auth or pg_database which are actually being stored in the database itself. Having an automatically maintained file and a manually maintained file is going to raise some tricky problems. In Oracle they have exactly the same issue. In that case the automatically maintained one is actually kept in a binary format. You can dump it out in text format but unless you switch which one you're using it doesn't read the text format file at all. I assume they did this because working out the conflicts between the two was just too complex for users. I think we're fine with allowing users to use both but we should try to keep the two as separate as possible to avoid confusion. Keeping the auto.conf inside conf.d sounds like it will actually confuse users about which files they're supposed to edit and which belong to the system. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
