Re: Frontend error logging style

> On 30 Mar 2022, at 00:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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.

Thats my plan, once this lands I'll rebase the comments on top of your work and
we can have a separate discussion around them then.

> 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?

I'm not sure.  If, against the odds, these cases do happen then a user of a
localized build probably really want to see the error in language they can
easily understand and take in.

--
Daniel Gustafsson        https://vmware.com/