Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire
Дата
Msg-id 17004.1390419900@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire  (Christian Kruse <christian@2ndquadrant.com>)
Ответы Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire  (Christian Kruse <christian@2ndquadrant.com>)
Список pgsql-hackers
Christian Kruse <christian@2ndquadrant.com> writes:
>> However, the real problem here is that you shouldn't be calling ngettext
>> manually in an ereport context in the first place.  There is
>> infrastructure in place for that, and this isn't using it.

> Fixed in attached patch. I changed it from calling
> errorcontext(ngettext()) to calling errdetail_plural().

Well, is it context or detail?  Those fields have reasonably well defined
meanings IMO.

If we need errcontext_plural, let's add it, not adopt inferior solutions
just because that isn't there for lack of previous need.

But having said that, I think this is indeed detail not context.
(I kinda wonder whether some of the stuff that's now in the primary
message shouldn't be pushed to errdetail as well.  It looks like some
previous patches in this area have been lazy.)

While I'm griping, this message isn't even trying to follow the project's
message style guidelines.  Detail or context messages are supposed to be
complete sentence(s), with capitalization and punctuation to match.

Lastly, is this information that we want to be shipping to clients?
Perhaps from a security standpoint that's not such a wise idea, and
errdetail_log() is what should be used.
        regards, tom lane



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: plpgsql.consistent_into
Следующее
От: Greg Stark
Дата:
Сообщение: Re: proposal: hide application_name from other users