On Mon, Jun 18, 2018 at 6:42 AM, Michael Paquier <michael@paquier.xyz> wrote:
On Thu, Jun 14, 2018 at 09:50:33AM -0400, Robert Haas wrote: > On Mon, Jun 11, 2018 at 6:11 PM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: >> I would go as far as suggesting to remove qualifiers that indicate what >> the file is for (such as "relation mapping file"); relying on the path >> as indicator of what's going wrong should be sufficient, since it's an >> error that affects internals anyway, not anything that users can do much >> about. Keep variations to a minimum, to ease translator's work; >> sometimes it's hard enough to come up with good translations for things >> like "relation mapping file" in the first place, and they don't help the >> end user. > > +1. I think those things are often hard to phrase even in English. > It makes the messages long, awkward, and almost invariably the style > differs from one message to the next depending on the author and how > easy it is to describe the type of file involved.
Okay, so this makes two votes in favor of keeping the messages simple without context, shaped like "could not read file %s", with Robert and Alvaro, and two votes for keeping some context with Andres and I. Anybody else has an opinion to offer?
Count me in with Robert and Alvaro with a +0.5 :)
Please note that I think that some messages should keep some context anyway, for example the WAL-related information is useful. An example is this one where the offset is good to know about: + ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen), + (errmsg("could not read from log segment %s, offset %u: read %d bytes, expected %d", + fname, readOff, r, XLOG_BLCKSZ)));
Yeah, I think you'd need to make a call for the individual message to see how much it helps. In this one the context definitely does, in some others it doesn't.
