Robert Haas <robertmhaas@gmail.com> writes:
> There's that, too. But again, these messages are not can't-happen
> scenarios. The argument is just whether to reuse existing error
> message text (like "could not write file") or invent a new variation
> (like "could not write remapping file").
As long as the message includes the file name, which it surely oughta,
I don't see that we need any explanation of what Postgres thinks the
file is for. If someone cares about that they can reverse-engineer
it from the file name; while as you said upthread, most of the time
the directory path is going to be the key piece of useful information.
So +1 for "could not write file".
> Andres' argument (which is
> valid) is that distinguished messages make it easier to troubleshoot
> without needing to turn on verbose error messages. My argument (which
> I think is also valid) is that a user isn't likely to know what a
> remapping file is, and having more messages increases the translation
> burden. Is there a project policy on this topic?
I think Andres' argument is a thinly veiled version of "let's put the
routine name into the message text", which there definitely is project
policy against (see 49.3.13 in the message style guide). If you want to
know the code location where the error was thrown, the answer is to get
a verbose log, not to put identifying information into the user-facing
message text. And this is only partially-identifying information,
which seems like the worst of both worlds: you've got confused users and
overworked translators, and you still don't know exactly where it was
thrown from.
regards, tom lane