Claudio Natoli wrote:
>>Well, I'd say that depends on what the general direction is for the Unix
>>version. Do we want everything on the commandline, in the env, or both.
>>We should follow whatever is wanted there, IMHO. And if everything is
>>not available on the commandline, and *should not be*, then we need to
>>do something special for win32 there. Such as a registry key.
>>
>>
>
>In the backend, I see getenv calls for the following:
> "PATH"
> "PGDATA"
> "PGPORT"
> "PGDATESTYLE"
> "TZ"
> "PGCLIENTENCODING"
>
>PATH is irrelevant (if you inspect findbe.c, you'll see that registering the
>postmaster service with the full path name, as would only be sensible in any
>case, avoids any issues here), and PGDATA is a command line arg. PGPORT is
>also a command line arg, and, like the remaining three, can be set using the
>respective GUC variable (amusingly, the related code in guc.c mentions that
>the reason these parameters can also be set via env vars is "for historical
>reasons").
>
>AFAICS this is a non-issue.
>
>
>
Thank you, Claudio. That's what I thought might be the case (hence my
previous question ;-) )
BTW, PGDATA *must* be picked up from the environment - initdb uses this
to pass it to postgres rather than the command line switch because of
the amazingly brain dead shell mode used by the Windows version of
popen(), which chokes on multiple quoted strings.
The remaining issue I see which is somewhat related to this is: how do
we allow an installation path to be set at install time rather than at
configure time (in the usual Windows way)? And how do we do that and at
the same time provide for multiple installations on the same machine?
cheers
andrew