Re: proposal: additional error fields

On 1 May 2012 21:14, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
>> Maybe no one is convinced by any of this, but the fact is that the
>> SQLSTATE argument falls down when one considers that we aren't using
>> it in many cases of errors that clearly are severe.
>
> The reason that argument isn't convincing is that we *are* using a
> SQLSTATE for every such message; it's just defaulted to XX000.  AFAICT,
> it would be reasonable to treat all XX000 as alarm conditions until
> proven different.  If a given message is, in fact, not supposed to be
> "can't happen", then it shouldn't be going through elog().  We'd
> probably be needing to fix some places that were lazily coded as elogs,
> but under your proposal we would also have to touch every such place
> ... and thousands more besides.

Fair enough. Adjusting all of those elog calls may be excessive. The
argument could be made that what I've characterised as severe (which
is, as I've said, not entirely clear-cut) could be deduced from
SQLSTATE if we were to formalise the "can't happen errors are only
allowed to use elog()" convention into a hard rule. However, I think
it's critically important to make all of this easy and
well-documented. Severity should probably be part of the default
log_line_prefix.

Sorry for high-jacking your thread, Pavel.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services