On 12/14/2011 04:47 PM, Magnus Hagander wrote:
You say "the server can just delete it". But how will this work if the file is *not* in the data directory? If you are on a Debian style system for example, where all these files go in /etc/postgresql - wouldn't that suddenly require the postgres user to have write access in this directory? If it actually has to be the server that modifies the file, I think it *does* make sense for this file to live in the data directory...
Perhaps I should have softened the suggestion to "relocating the postgresql.conf makes it *possible* to have no user writable files in the data directory". That was one of the later additions I made, it didn't bake overnight before sending like the bulk did.
A Debian system might want it to stay in the data directory. If we consider this not normally touched by the user state information--they can poke it by hand, but the preferred way is to use pg_ctl--perhaps it could live in /var/run/postgresql instead. [Surely I'll find out momentarily, now that I've trolled everyone here who is more familiar than me with the rules around what goes into /var]
I think the bigger idea I was trying to support in this part is just how many benefits there are from breaking this role into one decoupled from the main server configuration. It's not a new suggestion, but I think it was cut down by backward compatibility concerns before being fully explored. It seems all of the good ways to provide cleaner UIs need that, and it surely gives better flexibility to packagers for it to float free from the config. Who can predict what people will end up doing in their packages. (And the Gentoo changes have proven it's not just Debian)
If we drag this conversation back toward the best way to provide that cleaner UI, but can pick up enough agreement that backward compatibility limited to the sort of migration ideas I outlined is acceptable, I'd be happy with that progress. Hopes of reaching that point is the reason I dumped time into those alternative include options.
-- Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
