From 991f3e5ab3f8196d18d5b313c81a5f744f3baaea Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Tue, 29 Jan 2013 17:06:26 -0500
Subject: Provide database object names as separate fields in error messages.
This patch addresses the problem that applications currently have to
extract object names from possibly-localized textual error messages,
if they want to know for example which index caused a UNIQUE_VIOLATION
failure. It adds new error message fields to the wire protocol, which
can carry the name of a table, table column, data type, or constraint
associated with the error. (Since the protocol spec has always instructed
clients to ignore unrecognized field types, this should not create any
compatibility problem.)
Support for providing these new fields has been added to just a limited set
of error reports (mainly, those in the "integrity constraint violation"
SQLSTATE class), but we will doubtless add them to more calls in future.
Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with
additional hacking by Tom Lane.
---
doc/src/sgml/errcodes.sgml | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
(limited to 'doc/src/sgml/errcodes.sgml')
diff --git a/doc/src/sgml/errcodes.sgml b/doc/src/sgml/errcodes.sgml
index 16cb6c7fcdb..40b4191c104 100644
--- a/doc/src/sgml/errcodes.sgml
+++ b/doc/src/sgml/errcodes.sgml
@@ -27,7 +27,7 @@
According to the standard, the first two characters of an error code
denote a class of errors, while the last three characters indicate
a specific condition within that class. Thus, an application that
- does not recognize the specific error code can still be able to infer
+ does not recognize the specific error code might still be able to infer
what to do from the error class.
@@ -42,13 +42,25 @@
Condition Name
is also
+ The symbol shown in the column Condition Name
is
the condition name to use in