> I seems to me that the existing situation is actually correct : > > The configuration is a property of the initialized database cluster, so > a logical place for it is in the root of said cluster. > > It is *not* a property of the installed binary distribution (e.g > /usr/local/pgsql/etc) - as you may have *several* database clusters > created using *this* binary distribution, each of which requiring a > different configuration. > > Having said that, I am ok about the 'include' idea.
What I am finding difficult in this debate is that people are so resistent, not to change, but to the idea that someone would want to manage the system in a different way than they would. Yes, there are probably many people who have multiple PostgreSQL database clusters installed and operating simultaneously on their systems. No one is saying that this needs to change in any way. IMHO my patch can do this in a self documenting way, thus making it easier to do, i.e. postmaster -C /etc/postgres/fundb.conf postmaster -C /etc/postgres/testdb.conf I think that is far more intuitive than: postmaster -D /some/path/who/knows/where/fundb postmaster -D /another/path/i/don/t/know/testdb (Sorry for the sarcasm :-) The point is, that configuration, including data cluster location, through the configuration file is where a lot of PostgreSQL admins would like to be. I understand the ease and historical nessesity of having everything in the PGDATA directory, and as I've said many many times, I'm not suggesting changing this default behavior, I simply want to add the features that would allow PostgreSQL to be managed similarly to more mainstream UNIX daemons like named, dhcpd, and so on. I have been using this patch for a while and it makes administration easier for me. What is difficult in this patch is that it is not technically a "SQL feature" which can be debated on functionality, it is more of a usability feature which, by nature, is quite subjective. After a certain point, people get polarized and debate sort of stops and discussion becomes stating and restating the same contrary opinions. It is frustrating. I think this is important, as I would not have written and maintained it otherwise, but by being a somewhat subjective feature I can't make any iron clad arguments for it. I can only say it makes administration easier for those who whould like PostgreSQL administered this way. If the prevailing view is "we don't think so," then it doesn't get put it, but it doesn't make my arguments any less valid. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
