database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-08 06:02:22 +03:00
Code Activity

Provide database object names as separate fields in error messages.

Browse Source 
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.
This commit is contained in:
Tom Lane
2013-01-29 17:06:26 -05:00
parent 89d00cbe01
commit 991f3e5ab3
27 changed files with 604 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
doc/src/sgml/errcodes.sgml
View File

@@ -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.
</para>
@@ -42,13 +42,25 @@
</para>
<para>
The symbol shown in the column <quote>Condition Name</quote> is also
The symbol shown in the column <quote>Condition Name</quote> is
the condition name to use in <application>PL/pgSQL</>. Condition
names can be written in either upper or lower case. (Note that
<application>PL/pgSQL</> does not recognize warning, as opposed to error,
condition names; those are classes 00, 01, and 02.)
</para>
<para>
For some types of errors, the server reports the name of a database object
(a table, table column, data type, or constraint) associated with the error;
for example, the name of the unique constraint that caused a
<symbol>unique_violation</> error. Such names are supplied in separate
fields of the error report message so that applications need not try to
extract them from the possibly-localized human-readable text of the message.
As of <productname>PostgreSQL</> 9.3, complete coverage for this feature
exists only for errors in SQLSTATE class 23 (integrity constraint
violation), but this is likely to be expanded in future.
</para>
<table id="errcodes-table">
<title><productname>PostgreSQL</productname> Error Codes</title>

64
doc/src/sgml/libpq.sgml
View File

@@ -2679,6 +2679,62 @@ char *PQresultErrorField(const PGresult *res, int fieldcode);
</listitem>
</varlistentry>
<varlistentry id="libpq-pg-diag-schema-name">
<term><symbol>PG_DIAG_SCHEMA_NAME</></term>
<listitem>
<para>
If the error was associated with a specific database object,
the name of the schema containing that object, if any.
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-pg-diag-table-name">
<term><symbol>PG_DIAG_TABLE_NAME</></term>
<listitem>
<para>
If the error was associated with a specific table, the name of
the table. (When this field is present, the schema name field
provides the name of the table's schema.)
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-pg-diag-column-name">
<term><symbol>PG_DIAG_COLUMN_NAME</></term>
<listitem>
<para>
If the error was associated with a specific table column, the
name of the column. (When this field is present, the schema
and table name fields identify the table.)
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-pg-diag-datatype-name">
<term><symbol>PG_DIAG_DATATYPE_NAME</></term>
<listitem>
<para>
If the error was associated with a specific datatype, the name
of the datatype. (When this field is present, the schema name
field provides the name of the datatype's schema.)
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-pg-diag-constraint-name">
<term><symbol>PG_DIAG_CONSTRAINT_NAME</></term>
<listitem>
<para>
If the error was associated with a specific constraint,
the name of the constraint. The table or domain that the
constraint belongs to is reported using the fields listed
above. (For this purpose, indexes are treated as constraints,
even if they weren't created with constraint syntax.)
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-pg-diag-source-file">
<term><symbol>PG_DIAG_SOURCE_FILE</></term>
<listitem>
@@ -2710,6 +2766,14 @@ char *PQresultErrorField(const PGresult *res, int fieldcode);
</variablelist>
</para>
<note>
<para>
The fields for schema name, table name, column name, datatype
name, and constraint name are supplied only for a limited number
of error types; see <xref linkend="errcodes-appendix">.
</para>
</note>
<para>
The client is responsible for formatting displayed information to meet
its needs; in particular it should break long lines as needed.

74
doc/src/sgml/protocol.sgml
View File

@@ -4757,6 +4757,72 @@ message.
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>s</>
</term>
<listitem>
<para>
Schema name: if the error was associated with a specific database
object, the name of the schema containing that object, if any.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>t</>
</term>
<listitem>
<para>
Table name: if the error was associated with a specific table, the
name of the table. (When this field is present, the schema name field
provides the name of the table's schema.)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>c</>
</term>
<listitem>
<para>
Column name: if the error was associated with a specific table column,
the name of the column. (When this field is present, the schema and
table name fields identify the table.)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>d</>
</term>
<listitem>
<para>
Datatype name: if the error was associated with a specific datatype,
the name of the datatype. (When this field is present, the schema
name field provides the name of the datatype's schema.)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>n</>
</term>
<listitem>
<para>
Constraint name: if the error was associated with a specific
constraint, the name of the constraint. The table or domain that the
constraint belongs to is reported using the fields listed above. (For
this purpose, indexes are treated as constraints, even if they weren't
created with constraint syntax.)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>F</>
@@ -4794,6 +4860,14 @@ message.
</variablelist>
<note>
<para>
The fields for schema name, table name, column name, datatype name, and
constraint name are supplied only for a limited number of error types;
see <xref linkend="errcodes-appendix">.
</para>
</note>
<para>
The client is responsible for formatting displayed information to meet its
needs; in particular it should break long lines as needed. Newline characters

56
doc/src/sgml/sources.sgml
View File

@@ -273,6 +273,45 @@ ereport(ERROR,
query processing.
</para>
</listitem>
<listitem>
<para>
<function>errtable(Relation rel)</function> specifies a relation whose
name and schema name should be included as auxiliary fields in the error
report.
</para>
</listitem>
<listitem>
<para>
<function>errtablecol(Relation rel, int attnum)</function> specifies
a column whose name, table name, and schema name should be included as
auxiliary fields in the error report.
</para>
</listitem>
<listitem>
<para>
<function>errtableconstraint(Relation rel, const char *conname)</function>
specifies a table constraint whose name, table name, and schema name
should be included as auxiliary fields in the error report. Indexes
should be considered to be constraints for this purpose, whether or
not they have an associated <structname>pg_constraint</> entry. Be
careful to pass the underlying heap relation, not the index itself, as
<literal>rel</>.
</para>
</listitem>
<listitem>
<para>
<function>errdatatype(Oid datatypeOid)</function> specifies a data
type whose name and schema name should be included as auxiliary fields
in the error report.
</para>
</listitem>
<listitem>
<para>
<function>errdomainconstraint(Oid datatypeOid, const char *conname)</function>
specifies a domain constraint whose name, domain name, and schema name
should be included as auxiliary fields in the error report.
</para>
</listitem>
<listitem>
<para>
<function>errcode_for_file_access()</> is a convenience function that
@@ -301,6 +340,23 @@ ereport(ERROR,
</itemizedlist>
</para>
<note>
<para>
At most one of the functions <function>errtable</>,
<function>errtablecol</>, <function>errtableconstraint</>,
<function>errdatatype</>, or <function>errdomainconstraint</> should
be used in an <function>ereport</> call. These functions exist to
allow applications to extract the name of a database object associated
with the error condition without having to examine the
potentially-localized error message text.
These functions should be used in error reports for which it's likely
that applications would wish to have automatic error handling. As of
<productname>PostgreSQL</> 9.3, complete coverage exists only for
errors in SQLSTATE class 23 (integrity constraint violation), but this
is likely to be expanded in future.
</para>
</note>
<para>
There is an older function <function>elog</> that is still heavily used.
An <function>elog</> call: