On 2019-02-21 15:56, Pierre Ducroquet wrote:
> I undestand these decisions, but it makes RLS quite fragile, with numerous un-
> documented side-effects. In order to save difficulties from future users, I
> wrote this patch to the documentation, listing the biggest restrictions I hit
> with RLS so far.
This appears to be the patch of record for this commit fest entry.
I agree that it would be useful to document and discuss better which
built-in operators are leak-proof and which are not. But I don't think
the CREATE POLICY reference page is the place to do it. Note that the
leak-proofness mechanism was originally introduced for security-barrier
views (an early form of RLS if you will), so someone could also
reasonably expect a discussion there.
I'm not sure of the best place to put it. Perhaps adding a section to
the Functions and Operators chapter would work.
Also, once you start such a list, there will be an expectation that it's
complete. So that would need to be ensured. You only list a few things
you found. Are there others? How do we keep this up to date?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services