I wrote:
> On closer inspection, the issue here is really that putting relpath.h/.c
> in common/ was completely misguided from the get-go. It's unnecessary:
> there's nothing outside the backend that uses it, except for
> contrib/pg_xlogdump which could very easily do without it. And relpath.h
> is a serious failure from a modularity standpoint anyway, because there is
> code all over the backend that has intimate familiarity with the pathname
> construction rules. We could possibly clean that up to the extent of
> being able to hide TABLESPACE_VERSION_DIRECTORY inside relpath.c, but what
> then? We'd still be talking about having CATALOG_VERSION_NO compiled into
> frontend code for any frontend code that actually made use of relpath.c,
> which is surely not such a great idea.
> So it seems to me the right fix for the relpath end of it is to push most
> of relpath.c back where it came from, which I think was backend/catalog/.
In short, what I'm proposing here is to revert commit
a73018392636ce832b09b5c31f6ad1f18a4643ea, lock stock n barrel.
According to the commit message, the point of that was to allow
pg_xlogdump to use relpath(), but I do not see it doing so; and
if it tried, I don't know where it would get an accurate value of
CATALOG_VERSION_NO from. So I think that was just poorly thought out.
What contrib/pg_xlogdump *is* using is the forkNames[] array, which
it uses to print the fork-number field of a BkpBlock symbolically.
I'm inclined to think that printing numerically is good enough there,
and a lot more robust.
Comments? If there's anyone who has a really good use-case for using
relpath() from outside the backend, better speak up.
regards, tom lane