On Mon, Dec 16, 2013 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Dec 16, 2013 at 6:01 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>>> Perhaps we should just introduce a marker that some such strings are not
>>> to be translated if they are of the unexpected kind. That would probably
>>> make debugging easier too ;)
>
>> Well, we have that: it's called elog. But that doesn't seem like the
>> right thing here.
>
> errmsg_internal?
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"). 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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
