Re: Frontend error logging style

> On 30 Mar 2022, at 00:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 29 Mar 2022, at 16:38, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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/