Postgresql 中文操作指南

55.8. Error and Notice Message Fields #

本部分描述可以在 ErrorResponse 和 NoticeResponse 消息中显示的字段。每种字段类型都有一个单字节标识令牌。请注意，给定的字段类型在每条消息中最多应显示一次。

This section describes the fields that can 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.

  • S

    • 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.

  • V

    • Severity: the field contents are ERROR, FATAL, or PANIC (in an error message), or WARNING, NOTICE, DEBUG, INFO, or LOG (in a notice message). This is identical to the S field except that the contents are never localized. This is present only in messages generated by PostgreSQL versions 9.6 and later.

  • C

    • Code: the SQLSTATE code for the error (see Appendix A). Not localizable. Always present.

  • M

    • Message: the primary human-readable error message. This should be accurate but terse (typically one line). Always present.

  • D

    • Detail: an optional secondary error message carrying more detail about the problem. Might run to multiple lines.

  • H

    • 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. Might run to multiple lines.

  • P

    • 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.

  • p

    • Internal position: this is defined the same as the P field, but it is used when the cursor position refers to an internally generated command rather than the one submitted by the client. The q field will always appear when this field appears.

  • q

    • Internal query: the text of a failed internally-generated command. This could be, for example, an SQL query issued by a PL/pgSQL function.

  • W

    • Where: an indication of the context in which the error occurred. Presently this includes a call stack traceback of active procedural language functions and internally-generated queries. The trace is one entry per line, most recent first.

  • s

    • Schema name: if the error was associated with a specific database object, the name of the schema containing that object, if any.

  • t

    • Table name: if the error was associated with a specific table, the name of the table. (Refer to the schema name field for the name of the table’s schema.)

  • c

    • Column name: if the error was associated with a specific table column, the name of the column. (Refer to the schema and table name fields to identify the table.)

  • d

    • Data type name: if the error was associated with a specific data type, the name of the data type. (Refer to the schema name field for the name of the data type’s schema.)

  • n

    • Constraint name: if the error was associated with a specific constraint, the name of the constraint. Refer to fields listed above for the associated table or domain. (For this purpose, indexes are treated as constraints, even if they weren’t created with constraint syntax.)

  • F

    • File: the file name of the source-code location where the error was reported.

  • L

    • Line: the line number of the source-code location where the error was reported.

  • R

    • Routine: the name of the source-code routine reporting the error.

Note

仅为有限数量的错误类型提供了模式名称、表名称、列名称、数据类型名称和约束名称的字段；请参见 Appendix A。前端不应假设其中任何字段的存在可以保证另一个字段的存在。核心错误源会遵守上述相互关系，但用户定义的函数可能会以其他方式使用这些字段。同样，客户端不应假设这些字段表示当前数据库中的当代对象。

The fields for schema name, table name, column name, data type name, and constraint name are supplied only for a limited number of error types; see Appendix A. Frontends should not assume that the presence of any of these fields guarantees the presence of another field. Core error sources observe the interrelationships noted above, but user-defined functions may use these fields in other ways. In the same vein, clients should not assume that these fields denote contemporary objects in the current database.

客户端负责格式化显示的信息以满足其需要；特别是它应根据需要拆分长行。错误消息字段中出现的换行符应视为段落符，而不是换行符。

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.