Re: RLS policy dump/restore failure due to elided type-casts

Поиск
Список
Период
Сортировка
От Karl Czajkowski
Тема Re: RLS policy dump/restore failure due to elided type-casts
Дата
Msg-id 20160421013753.GC7976@moraine.isi.edu
обсуждение исходный текст
Ответ на Re: RLS policy dump/restore failure due to elided type-casts  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-general
On Apr 20, David G. Johnston modulated:

> The problem here is that:
>
> scalar = ANY (array)
> is different than
> scalar = ANY (subquery)
>
> The normalization in ?ruleutils? is munging things so that a query that
> is written as "scalar = ANY(array) is transformed into one that is
> "scalar = ANY(subquery)"
>
> The extra parentheses and the cast are needed to force a "scalar = ANY
> (array)" where the basic expression looks like "scalar = ANY(subquery)"
>

Aha!  Thanks for that.  Now I realize there is a much simpler
workaround:

  CREATE POLICY delete_stuff ON stuff
  FOR DELETE USING ('example attribute value' = ANY ( current_attributes() ));

Somehow I fell into a pattern of writing scalar subqueries and I
forgot to just write the function invocation directly as an
expression!  This policy seems to round-trip through pg_dump
successfully. :-)

By the way, we expose our session context parameter as an array result
partly because we have other scenarios where we store row-level
application ACLs in array-typed columns and may want to do
array-to-array intersection tests in a policy expression.  It was my
intuition that gin indexing of those array-based ACL columns would
then make these policy expressions pretty fast to evaluate.


Karl



В списке pgsql-general по дате отправления:

Предыдущее
От:
Дата:
Сообщение: Re: How do BEGIN/COMMIT/ABORT operate in a nested SPI query?
Следующее
От: Karl Czajkowski
Дата:
Сообщение: Re: RLS policy dump/restore failure due to elided type-casts