Re: includedir_internal headers are not self-contained
От | Robert Haas |
---|---|
Тема | Re: includedir_internal headers are not self-contained |
Дата | |
Msg-id | CA+TgmoaAoL_H3Ro4ksqvMQhp+Unx7r7gEmb9X_ZnhOunB5-vSg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: includedir_internal headers are not self-contained (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: includedir_internal headers are not self-contained
|
Список | pgsql-hackers |
On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. I might be missing something, but, why? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: