RLS fails to work with UPDATE ... WHERE CURRENT OF

Attached test case patch shows how RLS fails to play nice with UPDATE
... WHERE CURRENT OF. If you run the revised rowsecurity regression
test against the master branch, the tests do not pass (which, ideally,
they would -- "expected" is actually what I expect here):

*** /home/pg/postgresql/src/test/regress/expected/rowsecurity.out
2015-06-06 15:04:02.142084059 -0700
--- /home/pg/postgresql/src/test/regress/results/rowsecurity.out
2015-06-06 15:04:09.014083800 -0700
***************
*** 2771,2780 ****

-- Still cannot UPDATE row through cursor:
UPDATE current_check SET payload = payload || '_new' WHERE CURRENT
OF current_check_cursor RETURNING *;
! currentid | payload | rlsuser
! -----------+---------+---------
! (0 rows)
! commit;
--
-- Clean up objects
--
--- 2771,2778 ----

-- Still cannot UPDATE row through cursor:
UPDATE current_check SET payload = payload || '_new' WHERE CURRENT
OF current_check_cursor RETURNING *;
! ERROR: WHERE CURRENT OF is not supported for this table type
! COMMIT;
--
-- Clean up objects
--

======================================================================

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.

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
--
Peter Geoghegan