2010-09-20 22:08:53 +02:00
|
|
|
<!-- doc/src/sgml/errcodes.sgml -->
|
2003-10-17 20:57:01 +02:00
|
|
|
|
|
|
|
<appendix id="errcodes-appendix">
|
|
|
|
<title><productname>PostgreSQL</productname> Error Codes</title>
|
|
|
|
|
|
|
|
<indexterm zone="errcodes-appendix">
|
|
|
|
<primary>error codes</primary>
|
|
|
|
<secondary>list of</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<para>
|
2004-05-14 20:04:02 +02:00
|
|
|
All messages emitted by the <productname>PostgreSQL</productname>
|
|
|
|
server are assigned five-character error codes that follow the SQL
|
2017-10-09 03:44:17 +02:00
|
|
|
standard's conventions for <quote>SQLSTATE</quote> codes. Applications
|
2004-05-14 20:04:02 +02:00
|
|
|
that need to know which error condition has occurred should usually
|
|
|
|
test the error code, rather than looking at the textual error
|
|
|
|
message. The error codes are less likely to change across
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>PostgreSQL</productname> releases, and also are not subject to
|
2004-05-14 20:04:02 +02:00
|
|
|
change due to localization of error messages. Note that some, but
|
2017-10-09 03:44:17 +02:00
|
|
|
not all, of the error codes produced by <productname>PostgreSQL</productname>
|
2004-05-14 20:04:02 +02:00
|
|
|
are defined by the SQL standard; some additional error codes for
|
|
|
|
conditions not defined by the standard have been invented or
|
|
|
|
borrowed from other databases.
|
2003-10-17 20:57:01 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
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
|
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.
2013-01-29 23:06:26 +01:00
|
|
|
does not recognize the specific error code might still be able to infer
|
2003-10-17 20:57:01 +02:00
|
|
|
what to do from the error class.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="errcodes-table"/> lists all the error codes defined in
|
2003-10-17 20:57:01 +02:00
|
|
|
<productname>PostgreSQL</productname> &version;. (Some are not actually
|
|
|
|
used at present, but are defined by the SQL standard.)
|
|
|
|
The error classes are also shown. For each error class there is a
|
2017-10-09 03:44:17 +02:00
|
|
|
<quote>standard</quote> error code having the last three characters
|
|
|
|
<literal>000</literal>. This code is used only for error conditions that fall
|
2003-10-17 20:57:01 +02:00
|
|
|
within the class but do not have any more-specific code assigned.
|
|
|
|
</para>
|
|
|
|
|
2004-08-01 01:04:58 +02:00
|
|
|
<para>
|
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.
2013-01-29 23:06:26 +01:00
|
|
|
The symbol shown in the column <quote>Condition Name</quote> is
|
2017-10-09 03:44:17 +02:00
|
|
|
the condition name to use in <application>PL/pgSQL</application>. Condition
|
2011-05-27 23:25:33 +02:00
|
|
|
names can be written in either upper or lower case. (Note that
|
2017-10-09 03:44:17 +02:00
|
|
|
<application>PL/pgSQL</application> does not recognize warning, as opposed to error,
|
2005-01-06 02:49:24 +01:00
|
|
|
condition names; those are classes 00, 01, and 02.)
|
2004-08-01 01:04:58 +02:00
|
|
|
</para>
|
|
|
|
|
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.
2013-01-29 23:06:26 +01:00
|
|
|
<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
|
2017-10-09 03:44:17 +02:00
|
|
|
<symbol>unique_violation</symbol> error. Such names are supplied in separate
|
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.
2013-01-29 23:06:26 +01:00
|
|
|
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.
|
2017-10-09 03:44:17 +02:00
|
|
|
As of <productname>PostgreSQL</productname> 9.3, complete coverage for this feature
|
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.
2013-01-29 23:06:26 +01:00
|
|
|
exists only for errors in SQLSTATE class 23 (integrity constraint
|
|
|
|
violation), but this is likely to be expanded in future.
|
|
|
|
</para>
|
|
|
|
|
2003-10-17 20:57:01 +02:00
|
|
|
|
|
|
|
<table id="errcodes-table">
|
|
|
|
<title><productname>PostgreSQL</productname> Error Codes</title>
|
|
|
|
|
2011-05-27 23:25:33 +02:00
|
|
|
<tgroup cols="2">
|
2017-11-23 15:39:47 +01:00
|
|
|
<colspec colnum="1" colname="errorcode"/>
|
|
|
|
<colspec colnum="2" colname="condname"/>
|
|
|
|
<spanspec namest="errorcode" nameend="condname" spanname="span12"/>
|
2005-12-08 22:01:52 +01:00
|
|
|
|
2003-10-17 20:57:01 +02:00
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Error Code</entry>
|
2008-05-16 00:39:49 +02:00
|
|
|
<entry>Condition Name</entry>
|
2003-10-17 20:57:01 +02:00
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
2011-02-04 04:32:49 +01:00
|
|
|
&errcodes-table;
|
2003-10-17 20:57:01 +02:00
|
|
|
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
|
|
|
|
|
|
|
|
</appendix>
|