I wrote:
> 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.)
Since nobody objected, I've committed something along this line.
include/common/ is now free of references to backend headers.
The patch is certainly too invasive to consider back-patching into
9.3, though.
Heikki Linnakangas <hlinnakan...@vmware.com> writes:
>> One idea would be to have relpath.h/.c expose a function (not a #define)
>> that returns the value of CATALOG_VERSION_NO compiled into it. Then,
>> if pg_rewind were to replace all its direct references to
>> CATALOG_VERSION_NO (including the value it checks against pg_control)
>> with calls of that function, consistency would be ensured.
> In pg_rewind, I'd like to compile CATALOG_VERSION_NO into the binary
> itself, because pg_rewind is quite version-specific. Even if it happens
> to work with libpgport from a different version, I would worry that
> there are directory layout changes that would need to be handled in
> pg_rewind for it to work safely. So I would like to lock it to a
> specific catalog version.
> To lock it down, I could call the function and check that it matches the
> compiled-in value of CATALOG_VERSION_NO, though. So a function works for
> me, even though I don't really need the flexibility.
I didn't do anything about this idea, but if you want to follow through
with it, feel free to add such a function.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
