Re: proposal: additional error fields

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Peter Geoghegan" <peter(at)2ndquadrant(dot)com>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Noah Misch" <noah(at)leadboat(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: additional error fields
Date: 2012-05-02 14:16:48
Message-ID: 4FA0FB8002000025000476DD@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:

> My guess is that all the ones defined in the SQL standard are
> "expected" errors, more or less by definition, and thus not
> interesting according to Peter G's criteria.

On a scan through the list, I didn't see any exceptions to that,
except for the "F0" class. To restate what the standard reserves
for standard SQLSTATE values in the form of a regular expression, it
looks like:

'^[0-4A-H][0-9A-Z][0-4A-H][0-9A-Z][0-9A-Z]$'

Eyeballing the errcode page in the docs, it looks like there are
PostgreSQL-assigned values that start with '5', 'P', and 'X'. That
"F0" class looks suspicious; are those really defined by standard or
did we encroach on standard naming space with PostgreSQL-specific
values?

We also have PostgreSQL-specific values in standard classes where we
use 'P' for the third character, which is fine.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-02 14:23:17 Re: proposal: additional error fields
Previous Message Alexander Korotkov 2012-05-02 13:57:05 Re: Patch: add conversion from pg_wchar to multibyte