Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire
Date
Msg-id 17004.1390419900@sss.pgh.pa.us
Whole thread Raw
In response to 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>)
Responses 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>)
List 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 by date:

Previous
From: Jim Nasby
Date:
Subject: Re: plpgsql.consistent_into
Next
From: Greg Stark
Date:
Subject: Re: proposal: hide application_name from other users