On 6 June 2015 at 23:28, Peter Geoghegan <pg@heroku.com> wrote:
> Attached test case patch shows how RLS fails to play nice with UPDATE
> ... WHERE CURRENT OF.
> [snip]
> What's actually occurring here is that the executor imagines that this
> involves a foreign table scan (although I suppose it's equivocating a
> little bit by not saying so explicitly) -- ExecEvalCurrentOfExpr()
> comments imply that that's the only reason why control should reach it
> in practice. It looks like RLS has added a new way that CURRENT OF can
> fail to be made into a TidScan qualification. It doesn't look like
> Dean's most recent round of RLS fixes [1] addressed this case, based
> on his remarks. This non-support of WHERE CURRENT OF certainly isn't
> documented, and so looks like a bug.
>
Well spotted. I agree that this is a bug. We could just say that WHERE
CURRENT OF isn't supported on a table with RLS, but I think that would
be overly limiting.
> Unfortunately, the fact that WHERE CURRENT OF doesn't already accept
> additional qualifications doesn't leave me optimistic about this bug
> being easy to fix -- consider the gymnastics performed by commit
> c29a9c37 to get an idea of what I mean. Maybe it should just be
> formally desupported with RLS, as a stopgap solution for 9.5.
>
> [1] http://www.postgresql.org/message-id/CAEZATCVE7hdtfZGCJN-oevVaWBtBGG8-fBCh9VhDBHuZrsWY5w@mail.gmail.com
Actually I think it is fixable just by allowing the CURRENT OF
expression to be pushed down into the subquery through the security
barrier view. The planner is then guaranteed to generate a TID scan,
filtering by any other RLS quals, which ought to be the optimal plan.
Patch attached.
Regards,
Dean
