On 2016/07/15 3:49, Tom Lane wrote:
On reflection, it seems to me that we've gone wrong by tying planning to
equality of user mappings at all, and the best way to get out of this is
to not do that. Instead, let's insist that a join can be pushed down only
if the checkAsUser fields of the relevant RTEs are equal. If they are,
then the same user mapping must apply to both at runtime, whatever it is
--- and we don't need to predetermine that. With this approach, the need
for plan invalidation due to user mapping changes goes away entirely.
+1
The situation where we potentially lose something is a case like
Etsuro-san's original example, where the query contains one foreign table
reference coming from a view and one coming from the outer query, or maybe
from a different view. In the two-views case we would have to not push
down the join if the views have different owners, even though perhaps both
owners will use the PUBLIC mapping at runtime. I think that's a narrow
enough case that we can just live with not optimizing it. In the
view-and-outer-query case, the simplest answer is that we can't push down
because zero is not equal to the view owner's OID. We could make that a
little better if we know that the query will be executed as the view
owner, so that the relevant user IDs will be the same at runtime. There
is already some mechanism in the plan cache to track whether a plan
depends on the identity of the user running it (for RLS), so we could use
that to enforce that a plan containing such a pushed-down join is only run
by the same user that owns the view.
Seems reasonable to me.
One thing I'm not sure about is: should we insist that a join can be
pushed down only if the checkAsUser fields of the relevant RTEs are
equal in the case where user mappings are meaningless to the FDW, like
file_fdw?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
