Peter Geoghegan <peter@2ndquadrant.com> wrote:
> Currently the following informal categories of error are bunched
> together at ERROR severity:
>
> * Integrity constraint violations
> * Very serious situations, like running out of disk space
> * Serious disasters that often relate to hardware failure, like
> "xlog flush request %X/%X is not satisfied --- flushed only to
> %X/%X"
> * Errors that if seen relate to a bug within PostgreSQL, with
> obscure error messages, as from most of the elog calls within the
> planner, for example.
You forgot a few:
* Syntax errors in submitted statements.
* State-related errors, like trying to execute VACUUM in a
transaction or trying to UPDATE a row in a READ ONLY transaction.
* Serialization failures.
* RAISE EXCEPTION from inside a function; often because of a
validation in a BEFORE trigger function. If you tilt your head just
right you can see these as constraint violations, but I think it is
different enough to deserve specific mention.
* Violations of security policy.
* Loss of connection to a client.
I'm sure I didn't cover them all, but the wide variety of causes
should be recognized when considering a change like adding a new
severity level. The fact is, these all are (or at least *should
be*) coded with a SQLSTATE to classify the nature of the problem.
Adding one more severity level forces us to examine every class of
error and determine whether it should be promoted to "severe".
Perhaps a better solution would be to allow some filtering of error
SQLSTATE values to determine what action is taken? Changes would be
more localized, and it would provide greater flexibility.
The comments earlier in the thread about this helping translation
don't make sense to me. In what way would a new severity level help
with that?
-Kevin
