From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Adam Guthrie <asguthrie(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: "plan should not reference subplan's variable" when using row level security |
Date: | 2016-02-24 20:45:53 |
Message-ID: | 20160224204553.GK3127@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
* Adam Guthrie (asguthrie(at)gmail(dot)com) wrote:
> On 24 February 2016 at 20:27, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Yeah, looks like a bug to me. My gut reaction is that we're pulling up
> > a subquery in a way that isn't possible and that plan shouldn't be
> > getting built/considered.
>
> Thanks - shall I go ahead and submit a bug report?
Sure.
> > As a work-around, until we fix it, you could create an sql function to
> > check for the existance of the id in 'a' and use that in the policy
> > definition.
>
> I've also discovered that using the following policy instead
>
> CREATE POLICY a_select ON b FOR SELECT
> USING ( a_id IN (SELECT id FROM a) );
>
> also seems to work around the issue.
Yes, that also works, but it could get painful if 'a' gets large. An
SQL function like:
select exists (select * from a where a.id = $1);
Would still use an indexed lookup against 'a'.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Karsten Hilbert | 2016-02-24 22:12:09 | check constraint problem during COPY while pg_upgrade-ing |
Previous Message | Adam Guthrie | 2016-02-24 20:35:04 | Re: "plan should not reference subplan's variable" when using row level security |