Bruce Momjian wrote:
> Andrew Dunstan wrote:
>> >I think we should use the relative-path method *unless* the configure
>> >command called out specific installation directories (that is, not
>> >just --prefix but --datadir and/or related options). If you use one of
>> >those then that absolute path should be used always, ie, you are
>> >specifically asking for a nonrelocatable install and that's what you
>> >should get.
>> >
>> >
>> >
>>
>> I think we are making this way too complicated in a quest for
>> flexibility that is of dubious value.
>>
>> I think we could adopt a simple rule: if you configure it for relocation
>> (and I think you should have to do that explicitly) then all paths are
>> relative to the binary location. If not, then full hardcoded paths are
>> used. No exceptions.
>>
>> Most people won't need this at all, I suspect - people who make binary
>> packages/installers for redistribution will find it a great boon.
>
> I think if we go for the plan outlined, we will not need a special
> configure flag. (People might decide to move the install dir long after
> they install it.) By default, everything sits under pgsql as pgsql/bin,
> pgsql/lib, etc. I can't see how making it relative is going to bite us
> unless folks move the binaries out of pgsql/bin. Is that common for
> installs that don't specify a special bindir?
>
Does that include a mechanism for -rpath?
Currently, if you have multiple installations of PostgreSQL on a server
and call ones psql or whatever explicitly, it is not loading another
ones libpq, but for sure the one belonging to its version. How does the
plan you're talking about cover this?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #