54.8. Поля сообщений с ошибками и замечаниями
В этом разделе описываются поля, которые могут содержаться в сообщениях ErrorResponse и NoticeResponse. Для каждого типа поля определён свой идентификационный маркер. Заметьте, что в сообщении может содержаться поле любого из этих типов, но не больше одного раза.
-
S Важность: поле содержит
ERROR,FATALилиPANIC(в сообщении об ошибке), либоWARNING,NOTICE,DEBUG,INFOилиLOG(в сообщении с замечанием), либо переведённые значения (ОШИБКА, ВАЖНО, ПАНИКА, ПРЕДУПРЕЖДЕНИЕ, ЗАМЕЧАНИЕ, ОТЛАДКА, ИНФОРМАЦИЯ, СООБЩЕНИЕ, соответственно). Это поле присутствует всегда.-
V Важность: поле содержит
ERROR,FATALилиPANIC(в сообщении об ошибке) либоWARNING,NOTICE,DEBUG,INFOилиLOG(в сообщении с замечанием). Это поле подобноS, но его содержимое никогда не переводится. Присутствует только в сообщениях, выдаваемых Postgres Pro версии 9.6 и новее.-
C Код: код SQLSTATE выданной ошибки (см. Приложение A). Не переводится на другие языки, присутствует всегда.
-
M Сообщение: основное сообщение об ошибке, предназначенное для человека. Должно быть точным, но кратким (обычно в одну строку). Присутствует всегда.
-
D Необязательное дополнительное сообщение об ошибке, передающее более детальную информацию о проблеме. Может занимать несколько строк.
-
H Подсказка: необязательное предложение решения проблемы. Оно должно отличаться от подробного описания тем, что предлагает совет (не обязательно подходящий во всех случаях), а не сухие факты. Может располагаться в нескольких строках.
-
P Позиция: значение поля представляет целочисленное число в ASCII, указывающее на положение ошибки в исходной строке запроса. Первый символ находится в позиции 1, при этом позиции отсчитываются по символам, а не по байтам.
-
p Внутренняя позиция: она определяется так же, как поле
P, но отражает положение ошибки во внутренне сгенерированной команде, а не в строке, переданной клиентом. Вместе с этим полем всегда присутствует полеq.-
q Внутренний запрос: текст внутренне сгенерированной команды, в которой произошла ошибка. Это может быть, например, SQL-запрос, выполняемый функцией на PL/pgSQL.
-
W Где: указывает на контекст, в котором произошла ошибка. В настоящее время включает трассировку стека вызовов текущей функции на процедурном языке и внутренне сгенерированных запросов. Записи трассировки разделяются по строкам, вначале последняя.
-
s Имя схемы: если ошибка связана с некоторым объектом базы данных, это поле содержит имя схемы, к которой относится объект (если такая есть).
-
t Имя таблицы: если ошибка связана с некоторой таблицей, это поле содержит имя таблицы. (Узнать имя схемы таблицы можно из соответствующего отдельного поля.)
-
c Имя столбца: если ошибка связана с некоторым столбцом таблицы, это поле содержит имя столбца. (Идентифицировать таблицу можно, обратившись к полям, содержащим имя таблицы и схемы.)
-
d Имя типа данных: если ошибка связана с некоторым типом данных, это поле содержит имя типа. (Узнать имя схемы типа можно из соответствующего поля.)
-
n Имя ограничения: если ошибка связана с некоторым ограничением, это поле содержит имя ограничения. Чтобы узнать, к какой таблице или домену она относится, обратитесь к полям, описанным выше. (В данном контексте индексы считаются ограничениями, даже если они были созданы не с синтаксисом ограничений.)
-
F Файл: имя файла с исходным кодом, в котором была обнаружена ошибка.
-
L Строка: номер строки в исходном коде, в которой была обнаружена ошибка.
-
R Программа: имя программы в исходном коде, в которой была обнаружена ошибка.
Примечание
Поля, содержащие имена схемы, таблицы, столбца, типа данных и ограничения, выдаются только для ограниченного числа типов ошибок; см. Приложение A. Клиенты не должны рассчитывать на то, что присутствие одного из полей обязательно влечёт присутствие другого поля. Системные источники ошибок устанавливают связь между ними, но пользовательские функции могут использовать эти поля по-другому. Подобным образом, клиенты не должны полагаться на то, что эти поля ссылаются на актуальные объекты в текущей базе данных.
Клиент отвечает за форматирование отображаемой информации в соответствии с его нуждами; в частности, он должен разбивать длинные строки, как требуется. Символы новой строки, встречающиеся в полях сообщения об ошибке, должны обрабатываться, как разрывы абзацев, а не строк.
54.8. Error and Notice Message Fields
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, orPANIC(in an error message), orWARNING,NOTICE,DEBUG,INFO, orLOG(in a notice message), or a localized translation of one of these. Always present.-
V Severity: the field contents are
ERROR,FATAL, orPANIC(in an error message), orWARNING,NOTICE,DEBUG,INFO, orLOG(in a notice message). This is identical to theSfield except that the contents are never localized. This is present only in messages generated by Postgres Pro 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
Pfield, but it is used when the cursor position refers to an internally generated command rather than the one submitted by the client. Theqfield will always appear when this field appears.-
q Internal query: the text of a failed internally-generated command. This could be, for example, a 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
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.
