Re: logical changeset generation v6.8

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: logical changeset generation v6.8
Дата
Msg-id CA+TgmobbdLcH16SZdn93d3Vm5DvcAV4uuSM-jnqZ=OAKbG9FeQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: logical changeset generation v6.8  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: logical changeset generation v6.8
Re: logical changeset generation v6.8
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: planner missing a trick for foreign tables w/OR conditions
Следующее
От: David Fetter
Дата:
Сообщение: Re: planner missing a trick for foreign tables w/OR conditions