Tom Lane wrote: > I don't see any great value in a separate postgresql.conf parameter for > each secondary config file; that just means clutter to me, especially > if we add more such files in future. I am also distinctly not in favor > of eliminating the PGDATA environment variable; that reads to me as > "we are going to force you to do it our way rather than the way you've > always done it, even if you like the old way".
The scripts needn't ignore PGDATA at all. Only postmaster. Since the vast majority of people start the postmaster from a script, this winds up being a minor issue, except for the fact that without PGDATA administrators will be able to count on looking at the output of 'ps' to determine where the postmaster is looking for either the config file or the data directory. In other words, they'll have somewhere to start from without having to poke through scripts that might not even have been used (what happens when a user defines PGDATA and starts a postmaster? The administrator will have to go to more extreme lengths, like using lsof, to figure out where the data directory is. Not all systems have such tools). > Comments? I agree with your assessment for the most part, except for PGDATA. There's no good reason I can think of for the postmaster to look at it. It's fine if it sets it for processes it forks to inherit, but it shouldn't pay attention to it on startup. Some people might complain, but there's little difference in doing a "postmaster -D $PGDATA" and just "postmaster", and people who are starting things by hand hopefully aren't so inflexible as to demand that PGDATA remain treated as-is. People who really care can create a simple little 'pm.sh' script that simply does a "postmaster -D $PGDATA", which will save them typing even over just doing a "postmaster" from the command line. -- Kevin Brown [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
