Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
