服务器代码中生成的错误、警告和日志消息应使用 ereport 或其旧版本 elog 创建。 此函数的使用非常复杂，需要一些解释。
每个消息都有两个必需的元素：一个严重级别（范围从 DEBUG 到 PANIC，在 src/include/utils/elog.h 中定义）和一个主要的消息文本。此外，还有可选元素，最常见的是遵循 SQL 规范的 SQLSTATE 约定的错误标识符代码。ereport 本身只是一个 shell 宏，主要用于在 C 源代码中使消息生成看起来像一个单独的函数调用，从而方便语法使用。ereport 直接接受的唯一参数是严重级别。主要消息文本和任何可选的消息元素是通过调用辅助函数（例如 errmsg）在 ereport 调用中生成的。
一个典型的 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)，情况就不是这样了；因此，不要这样做。
如果您在文档中发现任何不正确的内容，与您对特定功能的体验不符或需要进一步澄清的内容，请使用此表单来报告文档问题。