Bruce Momjian wrote:
Well, in a sense, it trades passing one parameter, PGDATA, for another. I see your point that we should specify configuration first, and letWhile this is true, it is not uncommon, and it is more or less expected by most UNIX admins.
everything pass from there. However, it does add extra configuration
parameters, and because you still need to specify/create pgdata, it adds
an extra level of abstraction to setting up the server.
Stop!!! symlinks are not sufficient. When happens when a native Win32 version comes out? there are no symlinks. Also, most of the admins I know don't like to use simlinks as they are not self documenting. Symlinks are "bad."Also, there is nothing preventing someone from symlinking the configuration files from pgdata to somewhere else.
The problem with that is that you are back to symlinking shared files. Symlinks are a kludge.I don't think separate params for each config file is good. At the most, I think we will specify the configuration _directory_ for all the config files, perhaps pgsql/etc, and have pgdata default to ../data, or honor $PGDATA. That might be the cleanest.
I don't see it as very messy, for instance:Of course, that now gives us $PGCONFIG and $PGDATA, and possible intraction if postgresql.conf specifies a different pgdata from $PGDATA. As you can see, it could get messy.
postmaster -C /etc/postgres/postgresql.conf -D /RAID0/postgres -p 5432
postmaster -C /etc/postgres/postgresql.conf -D /RAID1/postgres -p 5433
That looks like a real clean way to run multiple PostgreSQL servers on the same box using the same configuration files.
Not true, command line parameters, as a rule, override configuration file defaults.And, if you specify pgdata in postgresql.conf, it prevents you from using that file by different postmasters.
I think you are making it too complicated.My best guess would be to not specify pgdata in postgresql.conf, and have a new $PGCONFIG param to specify the configuration directory, but if we do that, $PGDATA/postgresql.conf becomes meaningless, which could also be confusing. Maybe we don't allow those files to exist in $PGDATA if $PGCONFIG is used, _and_ $PGCONFIG is not the same as $PGDATA. See, I am getting myself confused. :-)
I wouldn't remove the default configration set, it would be useful as a failsafe or maintainence feature.
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]