Re: [HACKERS] Better path-matching for package relocatability (was Re:

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martin Pitt <martin(at)piware(dot)de>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Better path-matching for package relocatability (was Re:
Date: 2005-12-22 03:29:02
Message-ID: 200512220329.jBM3T2F14275@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Tom Lane wrote:
> Well, more generally what we need is a better match algorithm in
> make_relative_path. After a few moment's thought I propose:
>
> * Determine the common prefix of the compiled-in target_path and
> bin_path (for typical cases this would be "/usr" or "/usr/local";
> worst case is that the common prefix is just "/"). Call everything
> to the right of the common prefix the "tail" of these paths. The
> currently expected scenario is that the tails are "share" and "bin",
> but there might be more than one directory level in them.
>
> * Try to match the tail of the bin_path to the end of the actual binary
> location (my_exec_path without the executable's name).
>
> * If match, take everything to the left of the match in my_exec_path,
> and append the tail of target_path to produce the result.
>
> * If no match, use target_path as-is, same as now.
>
> I think this would get right all of the cases the current code gets
> right, and more generally would work when we need to substitute N
> levels of directory names instead of just one. It may still be a
> few bricks shy of a load, however. Any thoughts?

Sounds fine. When I did the original code, I was very conservative
about where I would look in the fear I might hit something strange. Now
that we have used this code in product with little problem, having it be
more aggressive seems logical.

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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tatsuo Ishii 2005-12-22 05:11:45 Re: BUG #2120: Crash when doing UTF8<->ISO_8859_8 encoding
Previous Message Bruce Momjian 2005-12-22 03:17:30 Re: [BUGS] BUG #2120: Crash when doing UTF8<->ISO_8859_8 encoding conversion

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-12-22 03:37:09 Re: catalog corruption bug
Previous Message Manuel Sugawara 2005-12-22 03:16:26 to_char and i18n