On Thu, May 3, 2012 at 11:46 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> wrote:
>> Excerpts from Magnus Hagander's message:
>>> Tom Lane <tgl@sss.pgh.pa.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.
Well, nearby Tom and I discussed demoting the message to DEBUG1 when
no transaction is in progress. Presumably the two messages would
share the same SQL state, unless we're going to create separate SQL
states for connection-closed-not-in-a-txn and
connection-closed-in-a-txn; and yet I think there's a very decent
argument that you're much more likely to care about the latter than
the former.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
