Robert Haas <robertmhaas@gmail.com> writes:
> I have to admit it's been a few years since I've had to play with
> WAL_DEBUG, so I don't really remember what I was trying to do. But I
> don't see any real argument that three slash-separated numbers will be
> more useful to somebody who has to dig through this than a pathname,
> even an approximate pathname, and I think people wanting to figure out
> approximately where they need to look to find the data affected by the
> WAL record will be pretty common among people decoding WAL records.
Meh. I still think it's a bad idea to have CATALOG_VERSION_NO getting
compiled into libpgcommon.a, where there will be no way to cross-check
that it matches anything. But I guess I'm losing this argument.
However, we've absolutely got to get that reference out of
common/relpath.h. The usage of RelFileNode there is problematic
as well.
How about we change common/relpath.[hc] to export a single version of
relpath() that takes its arguments as separate plain OIDs, and then
make the other versions wrappers that are only declared in some
backend header? The wrappers could possibly be macros, allowing
things like pg_xlogdump to keep using them as long as they didn't
mind importing backend headers. (Though for the RelFileNode case this
would imply multiple evaluation of the macro argument, so maybe it's
not such a great idea.)
regards, tom lane
