Andrew Dunstan wrote:
> Binaries can find other binaries the way they do now: look in our own
> location, then in the path.
No, we can't look into the path. We have no information that says that
anything useful pertaining to our installation is in the path.
> Other files could be found by looking in 1) as per commandline (e.g.
> -L in initdb) 2) hardcoded location, 3) our-location/../share
Nothing says that ../share contains anything useful. Maybe it's
../share/pgsql, or maybe ../share/postgresql, or maybe
../share/postgresql-7.4.2 or maybe it's elsewhere altogether because
you have just moved your installation tree to make room for a new one.
We can't take guesses like this based on "usual installations".
The only hard facts that we can use are hardcoded/compiled-in locations
and explicit information passed via command-line arguments or
environment variables. None of this seems to be useful for Windows
installations. As far as I recall, the Windows installation routines
only ask you for one installation directory but not all the individual
ones. If this is true, then we could hardcode relative paths, but
maybe I'm mistaken. Can someone give a couple of full examples of
typical Windows installation layouts?
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
