Re: registry vs. environment (was re:binary

From: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
To: 'Magnus Hagander' <mha(at)sollentuna(dot)net>, Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: registry vs. environment (was re:binary
Date: 2004-02-13 14:17:08
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B55F2F1@harris.memetrics.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32


> 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.

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Responses

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Andrew Dunstan 2004-02-13 15:04:30 Re: registry vs. environment (was re:binary
Previous Message Magnus Hagander 2004-02-13 13:35:21 Re: registry vs. environment (was re:binary