在服务器代码中生成的错误、警告和日志消息应使用 ereport
或其较旧的同类 elog
创建。此函数的使用非常复杂,需要一些解释。
每条消息都包含两个必备元素:严重性级别(范围从 DEBUG
到 PANIC
,在 src/include/utils/elog.h
中定义)和主要消息文本。此外还有一些可选元素,其中最常见的是一个遵循 SQL 规范 SQLSTATE 约定的错误标识符代码。 ereport
本身只是一个 shell 宏,主要用于语法方便,使消息生成看起来像 C 源代码中的单个函数调用。 ereport
直接接受的唯一参数是严重性级别。主要消息文本和任何可选消息元素都是通过在 ereport
调用中调用辅助函数(例如 errmsg
)来生成的。
ereport
的典型调用可能如下所示
ereport(ERROR, errcode(ERRCODE_DIVISION_BY_ZERO), errmsg("division by zero"));
这指定了错误严重性级别 ERROR
(一个普通的错误)。 errcode
调用使用 src/include/utils/errcodes.h
中定义的宏指定 SQLSTATE 错误代码。 errmsg
调用提供主要消息文本。
您还会经常看到这种较旧的样式,在辅助函数调用周围添加了一对额外的括号
ereport(ERROR, (errcode(ERRCODE_DIVISION_BY_ZERO), errmsg("division by zero")));
在 PostgreSQL 12 版本之前需要添加额外的括号,但现在是可选的。
以下是一个更复杂的示例
ereport(ERROR, errcode(ERRCODE_AMBIGUOUS_FUNCTION), errmsg("function %s is not unique", func_signature_string(funcname, nargs, NIL, actual_arg_types)), errhint("Unable to choose a best candidate function. " "You might need to add explicit typecasts."));
这说明了使用格式代码将运行时值嵌入到消息文本中。此外,还提供了可选的 “提示” 消息。辅助函数调用可以按任何顺序编写,但通常 errcode
和 errmsg
首先出现。
如果严重性级别为 ERROR
或更高,则 ereport
会中止当前查询的执行,不会返回调用者。如果严重性级别低于 ERROR
,则 ereport
会正常返回。
用于 ereport
的可用辅助例程如下
errcode(sqlerrcode)
指定条件的 SQLSTATE 错误标识符代码。如果未调用此例程,则错误标识符在错误严重性级别为 ERROR
或更高时默认为 ERRCODE_INTERNAL_ERROR
,在错误级别为 WARNING
时默认为 ERRCODE_WARNING
,否则(对于 NOTICE
及以下)为 ERRCODE_SUCCESSFUL_COMPLETION
。虽然这些默认值通常很方便,但在省略 errcode()
调用之前,始终要考虑它们是否合适。
errmsg(const char *msg, ...)
指定主要错误消息文本,以及可能插入其中的运行时值。插入通过 sprintf
样式格式代码指定。除了 sprintf
接受的标准格式代码之外,格式代码 %m
还可用于插入 strerror
为 errno
的当前值返回的错误消息。 [16] %m
不需要 errmsg
参数列表中的任何对应项。请注意,在处理格式代码之前,消息字符串将通过 gettext
进行可能的本地化处理。
errmsg_internal(const char *msg, ...)
与 errmsg
相同,只是消息字符串不会被翻译,也不会包含在国际化消息字典中。这应该用于 “不可能发生” 的情况,这些情况可能不值得花费翻译工作。
errmsg_plural(const char *fmt_singular, const char *fmt_plural, unsigned long n, ...)
类似于 errmsg
,但支持消息的各种复数形式。 fmt_singular
是英文单数格式,fmt_plural
是英文复数格式,n
是确定需要使用哪种复数形式的整数值,其余参数根据选定的格式字符串进行格式化。有关更多信息,请参见 第 55.2.2 节。
errdetail(const char *msg, ...)
提供可选的 “详细信息” 消息;这应该在有看起来不适合放在主要消息中的附加信息时使用。消息字符串的处理方式与 errmsg
相同。
errdetail_internal(const char *msg, ...)
与 errdetail
相同,只是消息字符串不会被翻译,也不会包含在国际化消息字典中。这应该用于不值得花费翻译工作的详细信息消息,例如因为它们过于技术性,对大多数用户没有用。
errdetail_plural(const char *fmt_singular, const char *fmt_plural, unsigned long n, ...)
类似于 errdetail
,但支持消息的各种复数形式。有关更多信息,请参见 第 55.2.2 节。
errdetail_log(const char *msg, ...)
与 errdetail
相同,只是此字符串只发送到服务器日志,绝不发送到客户端。如果同时使用 errdetail
(或其上面的等效项)和 errdetail_log
,则一个字符串发送到客户端,另一个字符串发送到日志。这对过于敏感或过于庞大而无法包含在发送给客户端的报告中的错误详细信息很有用。
errdetail_log_plural(const char *fmt_singular, const char *fmt_plural, unsigned long n, ...)
类似于 errdetail_log
,但支持消息的各种复数形式。有关更多信息,请参见 第 55.2.2 节。
errhint(const char *msg, ...)
提供可选的 “提示” 消息;这应该在提供有关如何解决问题的建议时使用,而不是关于出现错误的实际详细信息。消息字符串的处理方式与 errmsg
相同。
errhint_plural(const char *fmt_singular, const char *fmt_plural, unsigned long n, ...)
类似于 errhint
,但支持消息的各种复数形式。有关更多信息,请参见 第 55.2.2 节。
errcontext(const char *msg, ...)
通常不会从 ereport
消息站点直接调用;而是在 error_context_stack
回调函数中使用,以提供有关发生错误的上下文的信息,例如 PL 函数中的当前位置。消息字符串的处理方式与 errmsg
相同。与其他辅助函数不同,此函数可以每个 ereport
调用多次调用;因此提供的后续字符串将用换行符分隔起来。
errposition(int cursorpos)
指定查询字符串中错误的文本位置。目前,它仅对在查询处理的词法和语法分析阶段检测到的错误有用。
errtable(Relation rel)
指定一个关系,其名称和模式名称应作为辅助字段包含在错误报告中。
errtablecol(Relation rel, int attnum)
指定一个列,其名称、表名和模式名称应作为辅助字段包含在错误报告中。
errtableconstraint(Relation rel, const char *conname)
指定一个表约束,其名称、表名和模式名应作为辅助字段包含在错误报告中。对于此目的,应将索引视为约束,无论它们是否具有关联的 pg_constraint
条目。注意将底层堆关系而不是索引本身作为 rel
传递。
errdatatype(Oid datatypeOid)
指定一个数据类型,其名称和模式名应作为辅助字段包含在错误报告中。
errdomainconstraint(Oid datatypeOid, const char *conname)
指定一个域约束,其名称、域名和模式名应作为辅助字段包含在错误报告中。
errcode_for_file_access()
是一个便利函数,用于为文件访问相关系统调用中的失败选择合适的 SQLSTATE 错误标识符。它使用保存的 errno
来确定要生成的错误代码。通常,这应该与主要错误消息文本中的 %m
结合使用。
errcode_for_socket_access()
是一个便利函数,用于为套接字相关系统调用中的失败选择合适的 SQLSTATE 错误标识符。
errhidestmt(bool hide_stmt)
可以被调用来指定是否抑制 postmaster 日志中消息的 STATEMENT:
部分。通常,如果消息文本已经包含当前语句,则这是合适的。
errhidecontext(bool hide_ctx)
可以被调用来指定是否抑制 postmaster 日志中消息的 CONTEXT:
部分。这应该只用于冗长的调试消息,其中重复包含上下文会导致日志过于膨胀。
在一个 ereport
调用中,最多应使用一个 errtable
、errtablecol
、errtableconstraint
、errdatatype
或 errdomainconstraint
函数。这些函数的存在是为了允许应用程序提取与错误条件关联的数据库对象的名称,而无需检查可能已本地化的错误消息文本。这些函数应用于应用程序可能希望对错误进行自动处理的错误报告。从 PostgreSQL 9.3 开始,仅对 SQLSTATE 类别 23(完整性约束违反)中的错误提供了完整覆盖率,但这可能会在将来得到扩展。
有一个较旧的函数 elog
,它仍然被广泛使用。一个 elog
调用
elog(level, "format string", ...);
与以下内容完全相同
ereport(level, errmsg_internal("format string", ...));
请注意,SQLSTATE 错误代码始终是默认的,并且消息字符串不受翻译。因此,elog
应该只用于内部错误和低级调试日志记录。任何可能对普通用户感兴趣的消息都应该通过 ereport
传递。尽管如此,系统中仍然存在足够多的内部“不可能发生”错误检查,因此 elog
仍然被广泛使用;对于那些消息,它的符号简明性更受欢迎。
有关编写良好错误消息的建议,请参阅 第 54.3 节.
[16] 也就是说,在到达 ereport
调用时当前的值;辅助报告例程中 errno
的更改不会影响它。如果你要在 errmsg
的参数列表中显式编写 strerror(errno)
,则情况并非如此;因此,不要这样做。
如果您在文档中发现任何不正确的内容、不符合您对特定功能的体验或需要进一步澄清,请使用 此表格 报告文档问题。