On 07/30/2013 11:12 AM, Greg Stark wrote: > 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.
Ah, misunderstood your point. We certainly don't need *two* conf.d's. > 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. I don't think you understood GSmith's argument. For Debian/Ubuntu sysadmins, configuration files live in /etc/, *period*. Even ones which were automatically generated. The packagers and scripters of that OS have taken a significant amount of trouble to make that so, including writing their own wrapper scripts around utilities for Postgres, Apache, etc., in order to support putting all configuration files in /etc/. Now we're proposing to break that *again*, by putting yet another configuration file in PGDATA, and making it impossible to relocate. That's fairly hostile to the concerns of possibly our most popular OSes. Saying "it's not a configuration file because it's automatic" is rather disingenuous. If you can set work_mem via postgresql.auto.conf, it's a configuration file, regardless of the means you used to set it. > 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'm not sure we won't end up in the same place as Oracle, eventually. We'll see. Re: allowing users to disable ALTER SYSTEM SET, I think we'll have to implement that before 9.4. comes out, for the simple reason that users of Puppet and other large-scale configuration management utilities will demand it. If you're managing 120 PostgreSQL servers using centrally version-controlled Chef recipes, the last thing in the world you want is having your DBAs bypass that via ALTER SYSTEM SET. HOWEVER, I think adding the ability to disable ALTER SYSTEM SET can (and should) be a second, separate patch. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers