Skip site navigation (1) Skip section navigation (2)

Re: proposal: additional error fields

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: additional error fields
Date: 2012-05-02 07:23:29
Message-ID: 1335943409.27046.3.camel@fsopti579.F-Secure.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On tis, 2012-05-01 at 20:13 -0400, Tom Lane wrote:
> I don't deny that we probably need to reclassify a few error cases,
> and fix some elogs that should be ereports, before this approach would
> be really workable.  My point is that it's *close*, whereas "let's
> invent some new error severities" is not close to reality and will
> break all sorts of stuff.

We might hit a road block because some of these sqlstates are defined by
the SQL standard.  But at least we should try this first, and if it
doesn't work make another field that contains the admin/server-level
severity instead of the client-side/flow-control severity level.


In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2012-05-02 08:52:11
Subject: Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
Previous:From: Vivek Singh RaghuwanshiDate: 2012-05-02 05:37:59
Subject: Features of Postgresql and Postgres-xc with MySQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group