| PostgreSQL 7.4 Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 44. Frontend/Backend Protocol | Fast Forward | Next |
This section describes the fields that may appear in ErrorResponse and NoticeResponse messages. Each field type has a single-byte identification token. Note that any given field type should appear at most once per message.
Severity: the field contents are ERROR, FATAL, or PANIC (in an error message), or WARNING, NOTICE, DEBUG, INFO, or LOG (in a notice message), or a localized translation of one of these. Always present.
Code: the SQLSTATE code for the error (see Appendix A). Not localizable. Always present.
Message: the primary human-readable error message. This should be accurate but terse (typically one line). Always present.
Detail: an optional secondary error message carrying more detail about the problem. May run to multiple lines.
Hint: an optional suggestion what to do about the problem. This is intended to differ from Detail in that it offers advice (potentially inappropriate) rather than hard facts. May run to multiple lines.
Position: the field value is a decimal ASCII integer, indicating an error cursor position as an index into the original query string. The first character has index 1, and positions are measured in characters not bytes.
Where: an indication of the context in which the error occurred. Presently this includes a call stack traceback of active PL functions. The trace is one entry per line, most recent first.
File: the file name of the source-code location where the error was reported.
Line: the line number of the source-code location where the error was reported.
Routine: the name of the source-code routine reporting the error.
The client is responsible for formatting displayed information to meet its needs; in particular it should break long lines as needed. Newline characters appearing in the error message fields should be treated as paragraph breaks, not line breaks.