Re: Oddity in handling of cached plans for FDW queries

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