Re: Identifying a message in emit_log_hook.

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Identifying a message in emit_log_hook.
Date: 2016-02-16 10:21:30
Message-ID: CANP8+jLX3Z10T=dZtRBGUWRgCfZtLiPf0=QaNmFwciaFv=H1cA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16 February 2016 at 09:47, Kyotaro HORIGUCHI <
horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:

> I'm planning to change the error level of a specific error
> message. We can use emit_log_hook for this purpose but we have
> no reliable means to identify what a message is.
>
> For messages without valid sqlerrcode, filename:lineno could be
> used to identify but lineno is too unstable. One possible and
> most straightforward way to solve this is defining identifiers
> covering all error messages but such identifiers are too hard to
> manage. ErrorData.message could also be used but NLS translation
> and placeholders prevent it from being identified by simple means
> like strcmp(3).
>
> As a solution for this problem, I'd like to porpose to have an
> additional member in the struct ErrorData to hold a message id,
> that is, the format string for errmsg(). This is not best but
> useful enough.
>
> It is somewhat a crude way, but the attached small patch would
> do.
>
> Is there any opinions or suggestions?
>

First, I support the concept of message ids and any work you do in moving
this forwards.

If you were to require message ids, how would this work for extensions?
Many things write to the log, so this solution would rely upon 100%
compliance with your new approach. I think that is unlikely to happen.

I suggest an approach that allows optionally accessing a message id by
hashing the English message text. That would allow people to identify
messages without relying on people labelling everything correctly, as well
as writing filters that do not depend upon language.

I'm guessing this would require making the pre-translated error text
available to plugins as well as translated form.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2016-02-16 10:25:31 Re: custom function for converting human readable sizes to bytes
Previous Message Fabien COELHO 2016-02-16 10:18:39 Re: extend pgbench expressions with functions