My patch only works on the PostgreSQL server code. No changes have been made to the initialization scripts.On Thu, 13 Feb 2003, mlw wrote:Robert Treat wrote:On Thu, 2003-02-13 at 09:23, mlw wrote:I deal with a number of PG databases on a number of sites, and it is a real pain in the ass to get to a PG box and hunt around for data directory so as to be able to administer the system. What's really annoying is when you have to find the data directory when someone else set up the system.You realize that the actual code feature doesn't necessarily help this case, right? Putting configuration in /etc and having a configuration file option on the command line are separate concepts. I think the feature is worthwhile, but I have some initial condition functionality questions that may have been answered in the previous patch, but I don't remember at this point. Mostly these have to deal with initial creation. Does the user specify an output location to initdb, do they just specify a data dir as now where the configuration goes but then they need to move it somewhere, does initdb now do nothing relating to configuration file and the user should make one on his own. Related, is the admin expected to have already made (say) /etc/postgresql to stick the config in and set the permissions correctly (since initdb doesn't run as root)?
The patch declares three extra configuration file parameters:
hbafile= '/etc/postgres/pg_hba.conf'
identfile='/etc/postgres/pg_ident.conf'
datadir='/RAID0/postgres'
The command line option is a capital 'C,' as in:
postmaster -C /etc/postgresql.conf
I have no problem leaving the default configuration files remaining in the data directory as sort of a maintenance / boot strap sort of thing, so I don't see any reason to alter the installation.
As for this feature helping or not, I think it will. I think it accomplishes two things:
(1) Separates configuration from data.
(2) Allows an administrator to create a convention across multiple systems regardless of the location and mount points of the database storage.
(3) Lastly, it is a familiar methodology to DBAs not familiar with PostgreSQL.
Again, I don't see a valid reason for not including the patch. Yes, if you don't want to configure PostgreSQL that way, then so be it, but why not add the functionality for those who do?
I can envision the configuration file methodology of managing a database becoming the "preferred" approach over time as it is a more familiar and standard way of configuring servers on UNIX.
