Re: Better path-matching for package relocatability (was Re:
От | Bruce Momjian |
---|---|
Тема | Re: Better path-matching for package relocatability (was Re: |
Дата | |
Msg-id | 200512220329.jBM3T2F14275@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Better path-matching for package relocatability (was Re: [BUGS] horology regression test failure) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: