Tom Lane wrote:
>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>
>>My idea is to write a /port function that uses various methods to find
>>the needed files. We could look in the relative location first, and if
>>the needed file is not found, look in the hardcoded directory.
>>
>>
>
>I think a "search until you find something" approach would be a really
>bad idea. Particularly on a machine with multiple PG versions installed
>(and that has surely got to be a likely situation for people who are
>wanting to move things around). It seems entirely too likely that you
>would find the wrong version of some file.
>
>So ISTM that the location in which a given installation looks for its
>associated files should be completely predictable and *not* depend on
>whether it finds something there.
>
I agree.
>
>I'm fine with offering an option to make that location be relative to
>where the executable came from. But not with nondeterminism.
>
>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.
cheers
andrew
