Re: "unexpected EOF" messages

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Magnus Hagander" <magnus(at)hagander(dot)net>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: "unexpected EOF" messages
Date: 2012-05-03 15:46:49
Message-ID: 4FA26219020000250004774C@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Magnus Hagander's message:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> In the context of yesterday's discussions, I wonder whether a
>>> filter by SQLSTATE would be appropriate.
>>
>> I'm worried it's not really granular enough.
>
> Yeah.

Just to be sure we're not inventing a problem here, can someone
produce an example of a situation where it would not be granular
enough (assuming we correct bad SQLSTATE choices where they exist)?

I count 232 distinct SQLSTATE values (139 standard values and 93
PostgreSQL-specific values), and we can create more if we
want them; although I would recommend against doing that to get
finer resolution on a standard SQLSTATE value. A standard value
which is too coarse would be the strongest argument for adding some
other mechanism, IMO. If we do, I would be inclined toward
something to identify distinct conditions within a SQLSTATE, rather
than some overarching independent mechanism.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-03 16:04:15 Re: Advisory locks seem rather broken
Previous Message Robert Haas 2012-05-03 15:46:06 Re: "unexpected EOF" messages