Re: Frontend error logging style
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
Andres Freund <andres@anarazel.de>,
Robert Haas <robertmhaas@gmail.com>,
Michael Paquier <michael@paquier.xyz>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-03-29T22:38:30Z
Lists: 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
Commits
-
logging: Also add the command prefix to detail and hint messages
- a8cca6026e99 15.0 landed
-
Remove not-very-useful early checks of __pg_log_level in logging.h.
- 2c9381840fe2 15.0 landed
-
Improve frontend error logging style.
- 9a374b77fb53 15.0 landed
-
Apply PGDLLIMPORT markings broadly.
- 8ec569479fc2 15.0 cited