On 2018-06-11 18:11:05 -0400, Alvaro Herrera wrote:
> As for the messages, I propose to make them more regular, i.e. always
> use the wording "could not read from file "%s": read %d, expected %zu",
> avoiding variations such as
> not enough data in file \"%s\": %d read, %d expected"
> could not read compressed file \"%s\": read %d out of %zu
> could not read any data from log segment %s, offset %u, length %lu
> and others that appear in other places. (In the last case, I even go as
> far as proposing "read %d, expected %zu" where the the first %d is
> constant zero. Extra points if the sprintf format specifiers are always
> the same (say %zu) instead of, say, %d in odd places.
> 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.
If we go there, why not wrap the read/write/etc calls into a wrapper,
including the error handling?
I'm not quite convinced that "relation mapping file" doesn't provide any
information. It's likley to be easier to search for than a specific
filename, particularly if there's oids or such in the name...
Greetings,
Andres Freund