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:04:42 |
Message-ID: | CAKFQuwaiBXNFyFXAezOqyopYFgJ-cAn+Fe4MCt_y1eMgp9y3uQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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...?).
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-04-21 01:05:49 | Re: RLS policy dump/restore failure due to elided type-casts |
Previous Message | David G. Johnston | 2016-04-21 00:55:12 | Re: RLS policy dump/restore failure due to elided type-casts |