Bruce Momjian wrote: > 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. > > 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.
Uh...why are we having to mess with environment variables at all? It's one thing for shell scripts to make use of them, but another thing entirely for an executable like the postmaster to do the same. Seems logical to me to eliminate the use of $PGDATA in the postmaster entirely. It usually gets started from a shell script, so let the shell script pass the appropriate parameter telling the postmaster where to find the data, or the config files, or whatever. > And, if you specify pgdata in postgresql.conf, it prevents you from > using that file by different postmasters. Not at all. Don't GUC variables that are specified on the command line override the ones in the configuration file? > 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 think the solution is real simple: 1. Eliminate the use of $PGDATA in the postmaster. It causes far more headaches than it's worth. Instead, require that -D be passed on the command line. It's fine if the postmaster *sets* $PGDATA in order to minimize any changes that need to be made elsewhere, but the postmaster should not use it until it sets it. The postmaster right now reads all the config files (including postgresql.conf) from the directory specified by the -D option. Keep it that way. 2. Add a GUC variable that specifies where the data is. If this variable is not defined either on the command line or in the config file, then assume that the data is in the same place as the config file. Obviously files like PG_VERSION are associated with the data and not with the config, so they get treated appropriately. The above addresses *everyone's* concerns that I've seen thus far, I think. Thoughts? -- Kevin Brown [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly