Ограничение агрегатных / оконных функций в условиях политики безопасности на уровне строк Postgres

Мне удалось успешно использовать dense_rank() over (order by...) который AFAIK является оконной функцией - в условиях политики безопасности на уровне строк postgres.

Однако в документации говорится

Любое условное выражение SQL (возвращающее логическое значение). Условное выражение не может содержать агрегатных или оконных функций

(курсив мой).

Может ли кто-нибудь объяснить это ограничение и привести пример его применения?

Спасибо.


postgresql row-level-security window-functions
person Pyrocks    schedule 13.01.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

По сути, он говорит вам, что каждая строка независима в отношении безопасности на уровне строк.

Рассмотрим таблицу ниже:

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

Есть несколько (разрешительных) политик:

  1. field1 = 'value1'
  2. field1 = 'value2'
  3. SUM (field2)> 10 (запрещено, но давайте представим, что вы можете его определить)

Вам предоставлены политики №2 и 3. Вы можете просматривать и обновлять только последнюю запись.
... Пока вы не выполните UPDATE table SET value2 = 11.

Это действительно плохо с точки зрения:

  • Безопасность. Вы можете «предоставить себе» доступ к записям как пользователь (не как администратор).
  • Техническое обслуживание. Записи в такой базе данных будут появляться / исчезать случайным образом.
  • Производительность. Оценка такой политики потребовала бы очень больших затрат.

Интересно, что вы можете определять политики как MyField IN (SELECT MyOtherField FROM MyOtherTable), и в этом случае все зависит от того, что вы определили в MyOtherTable (он предназначен для использования с FK / PK).

person FXD    schedule 13.01.2019
comment
В этом есть смысл. Я использую плотный_ранк в пределах EXISTS - поэтому я предполагаю, что это допустимое использование. Спасибо! - person Pyrocks; 14.01.2019
comment
Вы имеете в виду EXISTS, который находится в обычном запросе? - person FXD; 14.01.2019
comment
Интересно ... Это сложный вопрос. - person FXD; 14.01.2019