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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Karl Czajkowski <karlcz(at)isi(dot)edu>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: RLS policy dump/restore failure due to elided type-casts
Date: 2016-04-21 01:05:49
Message-ID: CAKFQuwa3Y3MriCSDY+uurJBjM46df=N5wbiFrOG2X1d7+JoudQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Apr 20, 2016 at 6:04 PM, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Wed, Apr 20, 2016 at 5:18 PM, Karl Czajkowski <karlcz(at)isi(dot)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.​

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2016-04-21 01:17:20 Re: RLS policy dump/restore failure due to elided type-casts
Previous Message David G. Johnston 2016-04-21 01:04:42 Re: RLS policy dump/restore failure due to elided type-casts