Re: Fixed directory locations in installs

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fixed directory locations in installs
Date: 2004-05-02 23:51:15
Message-ID: 200405030151.15837.peter_e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2004-05-03 00:49:14 Re: Fixed directory locations in installs
Previous Message Tom Lane 2004-05-02 23:50:46 Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2