Re: error messages in extended statistics
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-05-30T15:10:29Z
Lists: pgsql-hackers
On Wed, May 15, 2019 at 06:35:47PM +0200, Tomas Vondra wrote: >On Wed, May 15, 2019 at 12:17:29PM -0400, Alvaro Herrera wrote: >>On 2019-May-05, Tomas Vondra wrote: >> >>>OK, so here is a patch, using elog() for all places except for the >>>input function, where we simply report we don't accept those values. >> >>Hmm, does this actually work? I didn't know that elog() supported >>errcode()/errmsg()/etc. I thought the macro definition didn't allow for >>that. >> > >D'oh, it probably does not. I might not have tried to compile it before >sending it to the mailing list, not sure ... :-( > >>Anyway, since the messages are still passed with errmsg(), they would >>still end up in the message catalog, so this patch doesn't help my case. >>I would suggest that instead of changing ereport to elog, you should >>change errmsg() to errmsg_internal(). That prevents the translation >>marking, and achieves the desired effect. (You can verify by running >>"make update-po" in src/backend/ and seeing that the msgid no longer >>appears in postgres.pot). >> >>>Now, what about backpatch? It's a small tweak, but it makes the life a >>>bit easier for translators ... >> >>+1 for backpatching. >> Pushed and backpatched, changing most places to elog(). -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Make error logging in extended statistics more consistent
- 39c9efc15646 10.9 landed
- 9c9a74cd3257 11.4 landed
- fe415ff10408 12.0 landed