Hackers, ALTER SYSTEM SET has been committed and recovery.conf GUCs are being reviewed. I'm going to make a last case for conf.d in relation to these two patches before 9.4 goes out the door.
In 9.3, we added support for a config directory (conf.d), but have it disabled by default. For tool authors, this makes conf.d useless since you never know, on any given installation, whether it will be present/enabled or not. While we don't want to prevent users from disabling it, conf.d only becomes useful if it's present by default. There's a simple reason why: if you want to write a tool which manages postgresql.conf, you don't want the user to have to manually edit postgresql.conf (and create a directory) in order to enable the tool. I'm particularly thinking about this in relation to the merger of recovery.conf and postgresql.conf. There are several tools already (RepMgr, OminPITR, HandyRep, pgPool, etc.) which manage recovery.conf separately from postgresql.conf. These tools will want to continue managing recovery.conf as a separate file, even if it's /included in postgresql.conf now. If conf.d exists by default, and is enabled in postgresql.conf by default, this is easy: the tool just drops a recovery.conf file into conf.d. Changing file locations and variable names is a fairly simple exercise in backwards compatibility. If conf.d does NOT exist by default, things become complicated, and backwards compatibility for replication management tools becomes much harder. Yes, I'm also arguing that postgresql.auto.conf should go into conf.d. I said I'd bring that up again after ALTER SYSTEM SET was committed, and here it is. -- 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
