On Wed, Mar 16, 2016 at 4:10 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote:
> > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company