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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: RLS policy dump/restore failure due to elided type-casts
Дата
Msg-id CAKFQuwa3Y3MriCSDY+uurJBjM46df=N5wbiFrOG2X1d7+JoudQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RLS policy dump/restore failure due to elided type-casts  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-general
On Wed, Apr 20, 2016 at 6:04 PM, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Wed, Apr 20, 2016 at 5:18 PM, Karl Czajkowski <karlcz@isi.edu> wrote:

  CREATE POLICY delete_stuff ON stuff
  FOR DELETE USING ('example attribute value' = ANY ( ((SELECT current_attributes()))::text[] ));


The following (untested) structure should be immune to this problem...use the knowledge as you see ​fit.

USING ('example_attribute_value' = ANY ( ARRAY( SELECT unnest(attr) FROM current_attributes() ca (attr) ) )

I cannot imagine the ARRAY(...) being removed and its presence should force the scalar = ANY(array) interpretation.

This does seem broken and likely to be back-patched though - and unnest+ARRAY is definitely inefficient so there is a trade-off involved - but hopefully only in the short-term (a couple of months probably...?).


​Actually, the ARRAY is pointless - just use the scalar = ANY(subquery) form which the unnest makes work correctly.

David J.​
 

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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: RLS policy dump/restore failure due to elided type-casts
Следующее
От: Tom Lane
Дата:
Сообщение: Re: RLS policy dump/restore failure due to elided type-casts