Re: logical changeset generation v6.8

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logical changeset generation v6.8
Date: 2013-12-16 17:48:06
Message-ID: CA+TgmobbdLcH16SZdn93d3Vm5DvcAV4uuSM-jnqZ=OAKbG9FeQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 16, 2013 at 12:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Dec 16, 2013 at 6:01 AM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-12-16 18:02:00 Re: pg_rewarm status
Previous Message David Fetter 2013-12-16 17:48:02 Re: planner missing a trick for foreign tables w/OR conditions