Re: the case for machine-readable error fields

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: the case for machine-readable error fields
Date: 2009-08-04 22:38:04
Message-ID: 4A7871FC02000025000293A3@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> A minimum requirement for such a thing, in my opinion, is that
> *every* occurrence of one of the targeted SQLSTATE codes should be
> able to produce the same auxiliary fields with the same meanings.
> If you can't define it that way, then you haven't actually made
> things better than looking at the message text.

I would hope that SQLSTATE *categorizes* messages rather than uniquely
identifying them. If it is being used correctly (as I see it), there
could well be different specific messages within the category
identified by a SQLSTATE for which different identifiers are useful.

I'm not so interested in using this feature, personally; but I am
concerned about how the issue might affect our use of SQLSTATE, about
which I do care.

Many products have a sequence number to identify their messages in
addition to using SQLSTATE to classify them. That seems pretty
sensible to me.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-08-04 23:04:13 Re: Filtering dictionaries support and unaccent dictionary
Previous Message Tom Lane 2009-08-04 22:29:24 Re: head contrib is broken (crypto)