Re: Frontend error logging style

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Frontend error logging style
Дата
Msg-id 116100.1648593510@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Frontend error logging style  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: Frontend error logging style  (Greg Stark <stark@mit.edu>)
Re: Frontend error logging style  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
> On 29 Mar 2022, at 16:38, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
>> Most of these should probably be addressed separately from Tom's patch.

> Yeah, I think so too.

Agreed.  I tried to confine my patch to mechanical changes, except
for changing places where the detail/hint features could be used.
(I don't say that I yielded to temptation nowhere, because I don't
recall that for certain; but editing the message texts was not the
point of my patch.)

Feel free to work on a followup editing patch though.

Another thing that occurred to me as I looked at your list is that
I think a lot of these are nearly-can't-happen cases that we didn't
put a lot of effort into devising great error messages for.  Maybe
we should continue that approach, and in particular not put effort
into translating such messages.  That would suggest inventing
"pg_fatal_internal" and so forth, with the same functionality
except for not being gettext triggers, comparable to
errmsg_internal.  However, then somebody would have to make
judgment calls about which messages not to bother translating.
Do we want to go down that path?

            regards, tom lane



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: pgsql: Add 'basebackup_to_shell' contrib module.
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work