Re: error messages in extended statistics
| От | Tomas Vondra |
|---|---|
| Тема | Re: error messages in extended statistics |
| Дата | |
| Msg-id | 20190515163547.kcqn76j5lczzw5p2@development обсуждение исходный текст |
| Ответ на | Re: error messages in extended statistics (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Ответы |
Re: error messages in extended statistics
|
| Список | pgsql-hackers |
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. > OK. -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: