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.
If a query against a single table with no user mapping is legal, I don't see why pushing down a join between two tables neither of which has a user mapping shouldn't also be legal.
