From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: RLS fails to work with UPDATE ... WHERE CURRENT OF |
Date: | 2015-07-09 21:47:58 |
Message-ID: | 559EEC0E.1080003@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/08/2015 02:08 AM, Dean Rasheed wrote:
> 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.
This looks good to me. I have tested and don't find any issues with
it. Will commit in a day or so unless someone has objections.
Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJVnuwOAAoJEDfy90M199hlQY0QAIchkbm8cc1BTnZnoZ0vgoid
hzEENu1c8AjQSWxovEpW27C41koKBP47dVNTxq3orBr4lJU2Rh0MdEyw2mrUKpzs
rLUwgkoI0x7vzcLUv4ZclmkiY1+oOVxAocZBRwVFcMk0SgAinI6EJe9J5fAl0hOe
CQU9wQWptnvtkyZKyqELWtnzT3Y4Dk7Rk4MAtFpoGfamS4J5PVHBGGHIb7VfyVJ5
NMytTN4Wl/AVdFNIjoXrcQSOFV8gTs17KUwlCSFfFLnSDPlQpTICbIkTSR/APQFK
M0Xn/Frp3hVzrpU0poaElbz7TisjfijmVRUmLv6ZCHDPwVgLLtrL0PJlT2IKLzRf
qBUK2EHEZTXvfdWW4l2aSxY8v8gf7++aiIZYAT01uJsj2JIic4G4dI2KGZ1PQ/BI
EKo2QaBlI1KYeECAG7Ingg+SyB+E3Hf7LUAxSjbkX3O97GYkg1amrd8XtvxKk9v2
gtgerBAyGkWBbx9H8DqoMnhgzqhkAOHYHdCJpf2dSDVyP+Xp94CBhOBwgt9NryJq
083ydo/7jGXdjjWS33U1wTPOa78YlDL44c5UXQ07z3LzDQHvl1JUfTm9QxZPOaKX
ny5tJCafkCSjQfbrrykQ+lmFFM6JmIVOzZKktlfClk14ayQVe+YXsGetXNZmJARQ
xOn9wTAhK7DjBD7Mkb6R
=G/mB
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-07-09 23:06:11 | Re: WAL logging problem in 9.4.3? |
Previous Message | Peter Geoghegan | 2015-07-09 21:32:40 | Re: Further issues with jsonb semantics, documentation |