Re: includedir_internal headers are not self-contained
От | Tom Lane |
---|---|
Тема | Re: includedir_internal headers are not self-contained |
Дата | |
Msg-id | 21095.1398701670@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: includedir_internal headers are not self-contained (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: includedir_internal headers are not self-contained
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@2ndquadrant.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. So I wouldn't mind dropping that dependency on relpath. Not sure what to do for Heikki's pg_rewind, though. regards, tom lane
В списке pgsql-hackers по дате отправления: