On Mon, Jun 18, 2018 at 6:42 AM, Michael Paquier <mich...@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
> > <alvhe...@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.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
