Re: Better path-matching for package relocatability (was Re: - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Better path-matching for package relocatability (was Re:
Date
Msg-id 200512220329.jBM3T2F14275@candle.pha.pa.us
Whole thread Raw
In response to Better path-matching for package relocatability (was Re: [BUGS] horology regression test failure)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Manuel Sugawara
Date:
Subject: to_char and i18n
Next
From: Tom Lane
Date:
Subject: Re: catalog corruption bug