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
