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
