Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > >>> I get this since Tom's commit. > > Ah-hah. It fails if you do "make check" and have not got any > installation at the configured place, *and* the configured place > isn't under someplace like /home/postgres. The reason is that > relative_path doesn't work. On my test system, configured > with --prefix = '/home/tgl/testversion', we end up with > > PGBINDIR = '/home/tgl/testversion/bin' > PGSHAREDIR = '/home/tgl/testversion/share/postgresql' > > because Makefile.global attaches /postgresql to PGSHAREDIR. > The discrepancy in path length causes relative_path to > return false ... and even if it returned true, get_share_path > would do the wrong thing, because it assumes it need only append > /share after stripping /bin. > > The reason this only affects timezone is that there isn't anything > else in /share that the backend needs to access. However I'm not quite > sure why get_pkglib_path seems not to be having the same confusion... > > In short the "relative path" stuff still needs a lot more work.
Well, in the case you have an install prefix of /usr, we wouldn't want relative installs because you would have /usr/bin and /usr/lib/postgresql and that wouldn't be relocatable. I think the weird part is appending /postgresql on any install that doesn't already have a pgsql/postgresql in the directory path. That is pretty weird, and doesn't interact well with the relocation code. However, I can't think of a good way to clean that up. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
