| 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: | Whole Thread | Raw Message | 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.
| 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 |