Tatsuo Ishii <ishii@postgresql.org> writes:
> I described the problem with possibly localized "S" filed of
> ErrorResponse(and NoticeResponse) in Frontend/Backend protocol.
> http://archives.postgresql.org/pgsql-hackers/2012-05/msg00912.php
> So I would like to propose a solution for this (for 9.3): add new
> field to ErrorResponse and NoticeResponse. The new field will have the
> same value as "S" except that it's never localized. This will not only
> solve the problem I described but possibly reduce the cost to analyze
> the error/notice messages in the frontend programs.
This seems like a rather expensive solution to a problem that I'm not
really convinced is real. Why should a client program care about the
severity level to a greater extent than whether the message is
ErrorResponse or NoticeResponse? In particular, I'm entirely
unconvinced by your claim that pgpool ought to treat ERROR and FATAL
cases differently. Whatever it does about session termination ought to
be driven by the connection closure, not by the content of the message.
(As a counterexample, what if the backend crashes without delivering any
message at all?) Moreover, if we did add this starting in 9.3, it would
still be many years before clients could rely on it being provided,
which means you'd need some other solution anyway.
Another issue is that if we do this, we're essentially (IMO) promising
that the set of severity codes won't change in the future, which may
not be a good thing to promise.
> BTW, changing existing "S" field not to be localized would work but
> I'm afraid it breaks backward compatibility.
We made it localized intentionally, on the grounds that its principal
and probably sole use was for presentation to human users. I've not
heard previous complaints about that decision.
regards, tom lane
