>> Common practice, for one thing. Windows programs are typically
>> relocatable, and Windows admins regard programs that rely on
>> hardcoded paths very poorly indeed.
>
>OK, but how can that work in general?  How do other programs handle 
>this?  I don't think we should design a solution that goes 
>like "ok, if 
>we move that file from share to lib then we could get away with it for 
>now".  That will only postpone the potential problems.  There needs to 
>be a definite and fixed place where programs can go looking to 
>find the 
>files they need.  Maybe it should be stored in that registry thing?

To make it work more cross-platform, replace "that registry thing" with
"postgresql.conf". It's basically the same thing, except the registry
has a hierarchy model.

And yes, that's how most other programs handle it.


//Magnus

Sun, 2 May 2004 22:38:32 +0200
"Magnus Hagander" <mha@sollentuna.net>
Re: Fixed directory locations in installs
Magnus Hagander wrote:
> To make it work more cross-platform, replace "that registry thing"
> with "postgresql.conf". It's basically the same thing, except the
> registry has a hierarchy model.

That only works as long as all the files we want to refer to are used by 
the server.  But how will psql find /etc/psqlrc, how will libpq find 
pg_service.conf, how will pg_dumpall find pg_dump, etc.?


Sun, 2 May 2004 23:05:54 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: Fixed directory locations in installs
Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > To make it work more cross-platform, replace "that registry thing"
> > with "postgresql.conf". It's basically the same thing, except the
> > registry has a hierarchy model.
> 
> That only works as long as all the files we want to refer to are used by 
> the server.  But how will psql find /etc/psqlrc, how will libpq find 
> pg_service.conf, how will pg_dumpall find pg_dump, etc.?

Actually, postgresql.conf only works once they run initdb (and we have
PGDATA defined).  We still have the open issue of how initdb finds
postgresql.conf.sample unless we embed the file in the initdb binary
(double-yuck).

For pg_dump on Unix, we hopefully have it in our path, but on Win32, we
will not.

For Win32, we could use the registry.  For Unix, we can't use /etc
because we can't be sure we are root.  Can we create a dot-file in the
user's home directory during install?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sun, 2 May 2004 18:20:57 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Fixed directory locations in installs


Bruce Momjian wrote:

>Peter Eisentraut wrote:
>  
>
>>Magnus Hagander wrote:
>>    
>>
>>>To make it work more cross-platform, replace "that registry thing"
>>>with "postgresql.conf". It's basically the same thing, except the
>>>registry has a hierarchy model.
>>>      
>>>
>>That only works as long as all the files we want to refer to are used by 
>>the server.  But how will psql find /etc/psqlrc, how will libpq find 
>>pg_service.conf, how will pg_dumpall find pg_dump, etc.?
>>    
>>
>
>Actually, postgresql.conf only works once they run initdb (and we have
>PGDATA defined).  We still have the open issue of how initdb finds
>postgresql.conf.sample unless we embed the file in the initdb binary
>(double-yuck).
>
>For pg_dump on Unix, we hopefully have it in our path, but on Win32, we
>will not.
>
>For Win32, we could use the registry.  For Unix, we can't use /etc
>because we can't be sure we are root.  Can we create a dot-file in the
>user's home directory during install?
>  
>


We can't be sure we are Administrator either.

Binaries can find other binaries the way they do now: look in our own 
location, then 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

No config files / registry entries should be necessary, AFAICS.

cheers

andrew




Sun, 02 May 2004 18:57:50 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: Fixed directory locations in installs
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?


Mon, 3 May 2004 01:51:15 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: Fixed directory locations in installs


Peter Eisentraut wrote:

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

Well, assuming all the binaries are installed in one location our own 
location should do the trick.

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

The only one I can think is typical is all in one location, e.g. as if 
you had specified --prefix="c:/foo/postgresql"

But there might be more exotic animals out there.

cheers

andrew


Sun, 02 May 2004 20:49:14 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: Fixed directory locations in installs