今天，我们谈一谈Postgres 15的新功能，包括逻辑复制的改进和数据库范围内的ICU区域。
如果你不知道，Postgres 15 rc1就在眼前，我们可以期待Postgres 15的最终版本在未来几周内发布。
在逻辑复制中使用列列表来过滤数据
在这篇博文中，富士通团队的Vignesh描述了如何在逻辑复制中使用列列表来限制哪些数据被发送到逻辑复制流中。
这个功能的本质是，当你在主表上有一个CREATE PUBLICATION语句时，你现在实际上可以从表中指定一个应该包括在发布中的列列表。
这里需要知道的一件重要的事情是，你至少需要在公布中包括所有的REPLICA IDENTITY列。如果不包括它们，UPDATE或DELETE操作就不会有一个可以附加的引用。这也意味着如果你使用的是REPLICA IDENTITY FULL，这个新功能并不能真正帮助你，因为你不能指定一个列列表的子集，因为所有的列都很重要，或者是REPLICA IDENTITY的一部分。
现在，这种工作方式是，例如，我们可以说CREATE PUBLICATION为表 "雇员"，我们可以说 "id"、"name "和 "email "作为列。在这种情况下，其他列，如 "出生日期 "或他们所在的 "部门"，将被跳过。在订阅者中，你实际上可以有这些列存在，但它们需要是可忽略的。
Vignesh在他的文章中向我们介绍的另一个例子是一个名为 "学生 "的表。你可以看到不同的列被传递，在这种情况下，订阅者实际上根本没有这些列存在，所以你现在可以在订阅者上有一个与发布者定义不同的表定义，并且如预期那样工作。
你现在可以在订阅者上有一个与发布者定义不同的表定义，并且如预期那样工作。
跳过数据以减少网络流量，以及数据的相关性
这实际上是非常有用的，因为以前你总是不得不在周围保留大量不必要的数据。此外，它将帮助你只向用户提供相关的数据。很多时候，你只是在分析你的表的一个子集的信息。这将减少网络流量，所以你现在可以通过网络发送更少的数据作为复制流的一部分。如果你有一个非常大的列，但你不需要，你现在可以跳过这个列。
最后但并非最不重要的是，有时复制数据会产生安全影响。例如，如果你有一个 "用户 "表，你可能不想复制你的散列密码。但是，在你的环境的不同部分有一个用户的电子邮件，这可能是有帮助的。现在，有了新的逻辑复制列过滤器，你可以只说用户的 "id"、"email "而跳过所有其他的用户列。
总的来说，我认为这将使逻辑复制对更多的用例更加有用，避免人们今天使用的手动复制工具。
Postgres 15中的数据库范围内的ICU排序
我想谈的第二个特性是Postgres 15中的数据库范围的ICU整理。Peter Eisentraut在这里写了一篇关于它的很好的文章。ICU的支持早在Postgres 10中就已经加入了，如果你不熟悉的话，ICU的排序很重要，比如说排序。当你对一个表中的行进行排序时，你要根据某些规则来做，这些规则可能是特定的语言。例如，在德语中，你可能有德语umlauts，它们会影响某些东西的排序。
当你对表格中的行进行排序时，你要根据某些规则来进行，而这些规则可以是特定的语言。
传统上，这是用glibc完成的，而glibc或libc在不同的版本中存在各种问题，导致潜在的数据库损坏，因为他们并没有真正明确不同版本库之间排序的时间。
ICU的功能更多，它也有更明确的版本变化时间。现在有了Postgres 15，我们可以在整个数据库中使用某种ICU区域设置，确保ICU的版本划分也影响到事物的排序方式，现在在整个数据库中的应用是一致的。
实际上，在某些情况下，你仍然必须使用libc的locale，这些是一些遗留物，例如，在文本搜索代码中。所以请注意，在今天的Postgres 15中，虽然你可以在大部分数据库中默认为ICU语言，但在这一点上，你仍然必须指定libc语言。
实际上，在Postgres中从事这些功能的Peter将在未来的版本中解决这个问题。
总的来说，我认为对于很多用例来说，这将使ICU的使用范围更广，对人们更有用。
原文标题：5mins of Postgres E37: New in Postgres 15: Logical replication column filters & database-wide ICU collations
原文作者：Lukas Fittl
原文地址：https://pganalyze.com/blog/5mins-postgres-15-logical-replication-filters-database-wide-icu-collations
