2022年10月24日，迈克尔·帕奎尔 承诺 补丁：
Add support for regexps on database and user entries in pg_hba.conf As of this commit, any database or user entry beginning with a slash (/) is considered as a regular expression. This is particularly useful for users, as now there is no clean way to match pattern on multiple HBA lines. For example, a user name mapping with a regular expression needs first to match with a HBA line, and we would skip the follow-up HBA entries if the ident regexp does *not* match with what has matched in the HBA line. pg_hba.conf is able to handle multiple databases and roles with a comma-separated list of these, hence individual regular expressions that include commas need to be double-quoted. At authentication time, user and database names are now checked in the following order: - Arbitrary keywords (like "all", the ones beginning by '+' for membership check), that we know will never have a regexp. A fancy case is for physical WAL senders, we *have* to only match "replication" for the database. - Regular expression matching. - Exact match. The previous logic did the same, but without the regexp step. We have discussed as well the possibility to support regexp pattern matching for host names, but these happen to lead to tricky issues based on what I understand, particularly with host entries that have CIDRs. This commit relies heavily on the refactoring done in a903971 and fc579e1, so as the amount of code required to compile and execute regular expressions is now minimal. When parsing pg_hba.conf, all the computed regexps needs to explicitely free()'d, same as pg_ident.conf. Documentation and TAP tests are added to cover this feature, including cases where the regexps use commas (for clarity in the docs, coverage for the parsing logic in the tests). Note that this introduces a breakage with older versions, where a database or user name beginning with a slash are treated as something to check for an equal match. Per discussion, we have discarded this as being much of an issue in practice as it would require a cluster to have database and/or role names that begin with a slash, as well as HBA entries using these. Hence, the consistency gained with regexps in pg_ident.conf is more appealing in the long term. **This compatibility change should be mentioned in the release notes.**作者： 伯特兰·德鲁沃特 评论者： Jacob Champion， Tom Lane， Michael Paquier 讨论：https://postgr.es/m/fff0d7c1-8ad4-76a1-9db3-0ab6ec338bf7@amazon.com
提交消息基本上解释了所有内容，但让我快速讨论一下并展示一些示例。
pg_hba.conf file 用于决定谁可以连接到哪个数据库、从何处以及使用哪种身份验证方法。我写了更详细的内容 早些时候 当我解释如何解决一些问题时。
现在，文件的格式很简单。有两种类型的配置行：
- 当地 数据库 用户 方法 [选项]
- 主机* 数据库 用户 地址 方法 [选项]
此新更改修改了可以包含的内容，但在 数据库 和 用户 领域。
回顾一下，在 数据库 您可以有任意数量的数据库名称，分隔为 , （逗号）。
因此，例如，您可以有线条：
local db1,db2,postgres all trust
这将允许任何人连接到列出的 3 个数据库之一，而无需对谁是谁进行任何形式的验证。
在以下情况下 用户 字段，您有更多选择：
- 用户名
- 组名（角色）前缀为 + 标志
- 包含用户名列表的文件的名称，前缀为 @
而且，当然，您可以拥有任意数量的这些元素，用逗号分隔。
因此，例如：
local db1 depesz，postgres，+dbas，@/etc/postgres/cron.users.lst trust
将允许用户 depesz、Postgres、属于组的任何用户连接到 DB1 数据库实例，以及 中列出的任何用户 /etc/postgres/cron.users.lst 文件。
现在，在这两个领域（数据库 和 用户），我们可以添加 正则表达式，通过以它们为前缀 / （斜杠）。
那会是什么样子？例如像这样：
local /^db[0-9]+$，/^dispatch dispatch trust
会让我连接到两组数据库：
^db[0-9]+$– 任何名称以“db”开头，然后有一些（至少 1）位数字的数据库。然后是字符串的结尾。因此，例如：db1、db13123，但不是 db23b^depesz– 任何名称以 depesz 开头的数据库
同样，我可以在 用户 字段，例如这样：
host all /-rw$ 10.1.2.0/24 scram-sha-256 host all /-ro$ 10.0.0.0/8 scram-sha-256
这将允许任何名称以 -乌尔曼 登录，只要他们从 IP 连接是 10.1.2.* 之一，并且任何名称以 -ro 来自 IP 是 10.*.*.* 之一。
我认为它看起来很棒，并且在某些情况下允许更好的配置。好吧，只要你不介意正则表达式。但是，如果你不会过于复杂，它应该是非常非常有帮助的事情。
与往常一样，感谢所有参与者。
原文作者：迈克尔·帕奎尔
原文地址：https://www.depesz.com/2022/11/03/waiting-for-postgresql-16-add-support-for-regexps-on-database-and-user-entries-in-pg_hba-conf/
原文标题：Waiting for PostgreSQL 16 – Add support for regexps on database and user entries in pg_hba.conf
