Postgres行级安全策略条件中的聚合/窗口函数限制 [英] Aggregate/Window functions restriction in Postgres Row Level Security Policy conditions

问题描述

我已经能够成功地使用 dense_rank（）（按...排序）
，其中AFAIK是窗口函数-在postgres的行级安全策略条件中。

I've been successfully able to use a dense_rank() over (order by...) which AFAIK is a window function - in postgres' row level security policy conditions.

但是，文档状态

任何SQL条件表达式（返回布尔值）。 条件表达式不能包含任何聚合或窗口函数

（强调是我的）。

有人可以解释此限制并举例说明它的适用范围吗？

Can someone explain this restriction and give an example where it applies?

谢谢。

推荐答案

基本上，它告诉您关于行级安全性，每一行都是独立的。

Basically, it tells you that each row is independent in regard of row-level security.

考虑下表：

+---------------------+----------------+
| field1              | field2         |
+---------------------+----------------+
| value1              | 1              |
| value1              | 2              |
| value1              | 3              |
| value2              | 4              |
+---------------------+----------------+

有几种（宽松的）政策：

There are several (permissive) policies:

1. field1 ='value1'


2. field1 ='value2'


3. SUM（field2）> 10（禁止，但现在让我们想象一下您可以定义它）

您被授予策略2和3，因此您只能查看和更新​​最后一条记录。

...直到执行 UPDATE表SET value2 = 11 。

You were granted policies #2 and 3 so you can see and update the last record only.
... Until you execute UPDATE table SET value2 = 11.

这真的很糟糕：

• 安全性。您可以作为用户（而不是管理员）授予自己对记录的访问权限。


• 维护。记录将在此类数据库中随机出现/消失。


• 性能。这种策略的评估成本非常高。

• Security. You can "grant yourself" access to records, as a user (not as an admin).
• Maintenance. Records would keep appearing/disappearing randomly in such database.
• Performance. Such policy would have a very big cost to evaluate.

有趣的是，您可以将策略定义为 MyField IN（ SELECT MyOtherField FROM MyOtherTable），在这种情况下，这完全取决于您在 MyOtherTable 上定义的内容（旨在与FK / PK一起使用）

Interstingly, you can define policies as MyField IN (SELECT MyOtherField FROM MyOtherTable), in which case it all relies on what you defined on MyOtherTable (it is intended to be used with FK/PK).

这篇关于Postgres行级安全策略条件中的聚合/窗口函数限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！