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/>