Re: includedir_internal headers are not self-contained
От | Tom Lane |
---|---|
Тема | Re: includedir_internal headers are not self-contained |
Дата | |
Msg-id | 22497.1398705647@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: includedir_internal headers are not self-contained (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: includedir_internal headers are not self-contained
Re: includedir_internal headers are not self-contained |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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? It's more verbose, it's not actually any more information, and in many cases it's actively misleading, because what's printed is NOT the real file name --- it omits segment numbers for instance. As a particularly egregious example, in xact_desc_commit() we print a pathname including MAIN_FORKNUM, which is a flat out lie to the reader, because what will actually get deleted is all forks. So yeah, it's an anti-feature. BTW, for the same reasons I'm less than impressed with the uses of relpath in error messages in, eg, reorderbuffer.c: relation = RelationIdGetRelation(reloid); if (relation == NULL) elog(ERROR, "could open relation descriptor %s", relpathperm(change->data.tp.relnode, MAIN_FORKNUM)); Printing anything other than the relation OID here is irrelevant, misleading, and inconsistent with our practice everywhere else. Let's not even mention the missing "not" in the message text. regards, tom lane
В списке pgsql-hackers по дате отправления: