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 greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
