Re: Identifying a message in emit_log_hook.
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Identifying a message in emit_log_hook. |
Дата | |
Msg-id | 20160217.173407.262410494.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Identifying a message in emit_log_hook. (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Identifying a message in emit_log_hook.
|
Список | pgsql-hackers |
Hello, thank you for the opinions, At Tue, 16 Feb 2016 10:57:33 +0100, Pavel Stehule <pavel.stehule@gmail.com> wrote in <CAFj8pRCg0GpZwVB3ZdAw8YriWnZ+Ty6twQOCqpmXgcTvYXX-mQ@mail.gmail.com> > Hi > > 2016-02-16 10:47 GMT+01:00 Kyotaro HORIGUCHI < > horiguchi.kyotaro@lab.ntt.co.jp>: > > > Hello. > > > > 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? > > > > It looks like workaround. The fixing missing sqlerrcode is much better. Inventing a consistent system of sqlerrcode covering whole of the code would be an unsolvable problem. Even allocating sequence number or such to every error messages would be difficult to maintain. The "message id" called in this thread is a text finally passed to gettext(3) as "msgid". Although it is under the context of translation, it is usable when identifying an error by its messages text is enough. From such an aspect, this could be called both of a workaround or a solution. At Tue, 16 Feb 2016 10:21:30 +0000, Simon Riggs <simon@2ndQuadrant.com> wrote in <CANP8+jLX3Z10T=dZtRBGUWRgCfZtLiPf0=QaNmFwciaFv=H1cA@mail.gmail.com> > First, I support the concept of message ids and any work you do in moving > this forwards. Thank you for supporting this. > 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'm uncertain about the "message ids" you mention, but as written above, it is exactly the text passed to elog() or ereport(), then passed to gettext(3) as the parameter "msgid". Of couse this cannot be reliable for certain usage but usable enough for some usage. > 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. The hash code could be used for screening if it can be calculated at compile time, but we cannot detect synonyms because of lack of a central storage so anyway the pre-translated error text still should be available to exntensions. > I'm guessing this would require making the pre-translated error text > available to plugins as well as translated form. If I understand you correctly, edata->messgage_id in my patch is just what offers the pre-translated error text to plugins. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Andres FreundДата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl