为什么 PostgreSQL 仅限于“application_name”的 ASCII 字符？

Question

免责声明：我将 PostgreSQL 和 PostgreSQL 单独用于我的所有数据库。这不是某种“仇恨”。

这是困扰我多年的事情，但在这一点上，在2020年，它只是荒谬的。

来源：https : //www.postgresql.org/docs/current/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT

application_name 可以是任何少于 NAMEDATALEN 字符（标准版本中为 64 个字符）的字符串。它通常由应用程序在连接到服务器时设置。该名称将显示在 pg_stat_activity 视图中并包含在 CSV 日志条目中。它也可以通过 log_line_prefix 参数包含在常规日志条目中。在 application_name 值中只能使用可打印的 ASCII 字符。其他字符将替换为问号 (?)。

（强调我的。）

所以，自称“世界上最先进的开源关系数据库”不支持 Unicode/UTF-8 这个特定的东西，但在其他地方。它迫使我（和我的潜在老板，如果我有的话）看到一堆“???????????” 遍布控制面板，例如在 pgAdmin 4 中。

我听说这应该是出于“安全问题”的考虑。在他们设置“Unicode 引擎”之前的某个阶段设置了有关 application_name 的某些内容或类似的内容。我不明白。如果真的是这样，当然，力ASCII-只为应用程序名称时，它在最初的连接设置，但也允许使用Unicode / UTF-8后当设置应用程序名称，连接已经建立后使用，在正常查询“SET”关键字！

我不明白。为什么我被迫到处看到这些丑陋的问号，只是因为我的语言恰好包含的不仅仅是 A-Za-z？即使以英语为中心的数据库也可能有与其他语言相关的脚本或具有花哨名称的服务，因此即使 PG 项目以美国为中心，这仍然不能成为借口。

Answer 1

一个可怕的“为什么”问题......我认为人们在某个年龄已经长大了......

无论如何，我可以回答这个问题，这是一个很好的例子，说明您应该如何处理此类问题。这里的重点是 PostgreSQL，一个由全球许多人开发的免费开源软件，所有讨论和决定都向所有人开放。

首先，git blame在源代码上使用查找添加文档行和功能的提交。从2009 年 11 月 29 日起，您可以轻松找到8217cfbd991856d25d73b0f7afcf43d99f90b653。

接下来，您在那个时间附近的邮件列表档案中搜索讨论和提交的补丁。你会发现这个、这个和这个线程，其中包含一个详尽的讨论。

在那里提出的相关要点是：

1. 汤姆·莱恩 (Tom Lane) 在此消息中写道：

   想多了，如果能保证值在数据库编码中应该就够了；语句的日志记录已经将几乎所有合法的 DB 编码字符串写入日志，因此如果您有问题，那么您已经有问题需要解决。

   这对于普通的 SET 来说不是问题，但是 AFAIR 我们没有一个很好的故事来处理初始连接请求数据包中到达的非 ASCII 内容。也许是时候尝试做点什么了。或者我们可以将这些值限制为 ASCII。

2. 后来，在这封邮件中，他发现了另一个更严肃的考虑：

   还有一个问题：根据我对讨论的阅读（这很可能有缺陷），是否计划将应用程序名称中的可用字符限制为 ascii？

   这是建议的，但我认为最终的结果是不要打扰。

   我认为这是非常必要的，而不是可选的。提议的补丁将应用程序名称从一个后端传输到另一个后端，而无需任何编码转换。如果它包含非 ASCII 字符，这将导致在后端注入错误编码的数据，这是我们在最近的版本中一直在努力避免的。

   您对此唯一可以做的另一件事是尝试将数据从源后端的编码转换为目标的编码。当无法进行转换时，这将导致各种失败情况。

   ISTM 将名称限制为仅 ASCII 是最合理的权衡。当然，作为一个说英语的人，我在这里可能有点偏见——但对这个问题不采取任何行动似乎是不可接受的。

这其实是一个很好的理由。

在pg_stat_statements其中application_name显示，你看从集群中的所有数据库会话。现在不同的数据库可以有不同的编码，所以如果你允许在数据库编码中使用非 ASCII 字符，a SELECTonpg_stat_activity可能会返回一个在SELECT运行的数据库中无效的字符串。这在 PostgreSQL 中是不可接受的，它对损坏的数据是无情的。

因此，从某种意义上说，这种限制是因为PostgreSQL 是世界上最先进的开源关系数据库，而且肯定具有高标准的数据完整性。