On Mon, Nov 28, 2016 at 6:55 PM, Stephen Frost <sfr...@snowman.net> wrote: >> diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README >> [...] >> + Additional rules will be needed to support safe handling of join quals >> + when there is a mix of security levels among join quals; for example, it >> + will be necessary to prevent leaky higher-security-level quals from being >> + evaluated at a lower join level than other quals of lower security level. >> + Currently there is no need to consider that since security-prioritized >> + quals can only be single-table restriction quals coming from RLS policies >> + or security-barrier views, and thus enforcement only needs to happen at >> + the table scan level. With such extra rules, it should be possible to let >> + security-barrier views be flattened into the parent query, allowing more >> + flexibility of planning while still preserving required ordering of qual >> + evaluation. But that will come later. > > Are you thinking that we will be able to remove the cut-out in > is_simple_subquery() which currently punts whenever an RTE is marked as > security_barrier? That would certainly be excellent as, currently, even > if everything involved is leakproof, we may end up with a poor choice of > plan because the join in the security barrier view must be performed > first. Consider a case where we have two relativly large tables being > joined together in a security barrier view, but a join from outside > which is against a small table. A better plan would generally be to > join with the smaller table first and then join the resulting small set > against the remaining large table.
We have to be careful that we don't introduce new security holes while we're improving the plans. I guess this would be OK if the table, its target list, and its quals all happened to be leakproof, but otherwise not. Or am I confused? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers