Skip site navigation (1) Skip section navigation (2)

Re: proposal: additional error fields

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: additional error fields
Date: 2012-05-01 20:14:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Hannu KrosingDate: 2012-05-01 20:16:01
Subject: Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
Previous:From: Peter GeogheganDate: 2012-05-01 20:14:02
Subject: Re: proposal: additional error fields

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group