Re: BUG #6300: duplicate key value violates unique constraint

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, tigran(dot)mkrtchyan(at)desy(dot)de, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6300: duplicate key value violates unique constraint
Date: 2011-11-24 21:55:12
Message-ID: 1322171712.20912.26.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On tor, 2011-11-24 at 11:14 -0500, Robert Haas wrote:
> So I would propose to steer clear of the word "internal", because the
> really scary errors typically are not internal to PostgreSQL at all.
> What I think we want to distinguish between is things that are
> PEBKAC/GIGO, and everything else. In other words, if a particular
> error message can be caused by typing something stupid, unexpected,
> erroneous, or whatever into psql, it's just an error. But if no
> input, however misguided, should ever cause that symptom, then it's, I
> don't know what the terminology should be, say, a "severe error".

The current error levels are designed entirely in terms of the client
session behavior, that is,

warning -- things continue
error -- abort transaction
fatal -- abort session
panic -- abort everything

(more or less). For a client issuing statements and reading responses,
these levels make perfect sense.

What we need is a labeling system in terms of server behavior, which is
completely separate from these client levels. In principle, every
log-issuing statement (that is, ereport) should specify a client and a
server severity level.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2011-11-24 22:01:04 Re: libpq in android
Previous Message Alvaro Herrera 2011-11-24 20:31:50 Re: libpq in android