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