PostgreSQLサーバによって発行されるメッセージは全て、標準SQLにおける「SQLSTATE」コードの記述方法に従った、5文字のエラーコードが割り当てられています。 どのようなエラー条件が発生したかを把握しなければならないアプリケーションは、通常テキスト形式のエラーメッセージを確認するのではなく、このエラーコードを検査すべきです。 このエラーコードは、PostgreSQLリリースの違いによって変更することはあまりありません。また、エラーメッセージのローカライゼーションによる変更にも影響されません。 PostgreSQLで発行されるエラーコードのいくつか（全部ではありません）は、標準SQLで定義されていることに注意してください。 標準SQLで定義されていない追加のエラーコードは、独自のものであったり他のデータベースから取り入れたものです。

標準に従い、エラーコードの最初の2文字はエラーのクラスを表し、残り3文字がそのクラス内の特定条件を表します。 したがって、特定のエラーコードを認識できないアプリケーションであっても、エラークラスから何をすべきか推定できることがあります。

表 A.1は、PostgreSQL 16.4で定義されたエラーコードを全て一覧で示しています （標準SQLでは定義されていますが、現在実際に使用されていないものもあります）。 エラークラスも示しています。 各エラークラスには、残りの3文字が000となる「標準」エラーコードが存在します。 あるクラスの範囲内で発生したが、より特定のコードが割り当てられていないエラー条件のためだけに、このコードが使用されます。

「条件名」列に示されているシンボルはPL/pgSQLで使用している条件名です。 条件名は大文字もしくは小文字でも記述されます。（PL/pgSQLは、エラーの場合と異なり、警告の場合にはその状態名を認識しません。これらはクラス00と01と02です）。

いくつかのエラー型に対し、サーバはそのエラーに起因するデータベースオブジェクト（テーブル、テーブル列、データ型、もしくは制約）の名前を報告します。たとえば、unique_violationエラーの原因となった一意性制約の名前です。 これら名前はエラーレポート文書の分離されたフィールドに与えられます。これにより、アプリケーションは読んで理解できる翻訳されているかも知れない文書のテキストからそれらを抽出しようと試みる必要がなくなります。 PostgreSQL 9.3の時点で、この機能を完璧に保証する範囲はSQLSTATEクラス23（整合性制約違反）のみですが、将来的には十中八九拡張されそうです。