On Tue, Mar 15, 2016 at 6:44 AM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: > Here's patch which fixes the issue using Robert's idea.
Please at least check your patches with 'git diff --check'
Thanks.
before submitting them. And where it's not too much trouble, pgindent them. Or at least make them look something like what pgindent would have produced, instead of having the line lengths be all over the place.
Sorry. PFA the patch with git diff --check output fixed.
-- change the session user to view_owner and execute the statement. Because of -- change in session user, the plan should get invalidated and created again. --- While creating the plan, it should throw error since there is no user mapping --- available for view_owner. +-- The join will not be pushed down since the joining relations do not have a +-- valid user mapping.
Now what's going on here? It seems to me that either postgres_fdw requires a user mapping (in which case this ought to fail) or it doesn't (in which case this ought to push the join down). I don't understand how working but not pushing the join down can ever be the right behavior.
In 9.5, postgres_fdw allowed to prepare statements involving foreign tables without an associated user mapping as long as planning did not require the user mapping. Remember, planner would require user mapping in case use_remote_estimate is ON for that foreign table. The user mapping would be certainly required at the time of execution. So executing such a prepared statement would throw error. If somebody created a user mapping between prepare and execute, execute would not throw an error. A join can be pushed down only when user mappings associated with the joining relations are known and they match. But given the behavior of 9.5 we should let the prepare succeed, even if the join can not be pushed down because of unknown user mapping. Before this fix, the test was not letting the prepare succeed, which is not compliant with 9.5.
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
