| From: | Josh Snyder <josh(at)code406(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | PATCH: Add query for operators unusable with RLS to documentation |
| Date: | 2024-05-18 23:54:52 |
| Message-ID: | 5af3bf0c-5e0c-4128-81dc-084c5258b1af@code406.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
When deploying RLS, I was surprised to find that certain queries which used
only builtin indexes and operators had dramatically different query plans when
a policy is applied. In my case, the query `tsvector @@ tsquery` over a GIN
index was no longer able to use that index. I was able to find one other
instance [1] of someone being surprised by this behavior on the mailing lists.
The docs already discuss the LEAKPROOF semantics in the abstract, but I think
they place not enough focus on the idea that builtin operators can be (and
frequently are) not leakproof. Based on the query given in the attached patch,
I found that 387 operators are not leakproof versus 588 that are.
The attached patch updates the documentation to provide an easy query over
system catalogs as a way of determining which operators will no longer perform
well under RLS or a security-barrier view.
Thanks,
Josh
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-query-for-operators-unusable-with-RLS.patch | text/x-patch | 1.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2024-05-19 00:15:11 | Re: Sort functions with specialized comparators |
| Previous Message | Thomas Munro | 2024-05-18 23:47:52 | Re: Streaming read-ready sequential scan code |