Re: includedir_internal headers are not self-contained

On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> Tom Lane wrote:
>>> ... which might or might not be the same one that libpgcommon was compiled
>>> with, no? I don't think you're really protecting yourself against version
>>> skew that way.
>
>> The CATALOG_VERSION dependency in that code is a mistake which I didn't
>> notice back then. I can't put too much thought into this issue at this
>> time, but printing fork numbers rather than names seems pretty
>> user-unfriendly to me. Rather than a revert of the whole patch I
>> would hope for some different solution, if possible, though I can't
>> offer anything right now.
>
> I think it would be okay to have a common/ module that encapsulates
> fork names/numbers. It's relpath() and particularly
> TABLESPACE_VERSION_DIRECTORY that bother me from a dependency standpoint.
>
> As far as pg_xlogdump goes, I agree that symbolic fork names are probably
> nice, but I think the case for printing db/ts/rel OIDs as a pathname is a
> whole lot weaker --- to my taste, that's actually an anti-feature.

I might be missing something, but, why?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company