On Wed, Nov 29, 2017 at 5:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > AFAICT, [1] just demonstrates that nobody had thought about the scenario > up to that point, not that the subsequently chosen solution was a good > one.
But have a look at this: http://postgr.es/m/561e12d4.7040...@lab.ntt.co.jp That shows a case where, before 5fc4c26db5120bd90348b6ee3101fcddfdf54800, a query that required the foreign table to do an EPQ recheck produced an unambiguously wrong answer; the query stipulates that inttab.a = ft1.a but the row returned lacks that property. I think this clearly shows that EPQ rechecks are needed at least for FDW paths that are parameterized. However, I guess that doesn't actually refute your point, which IIUC is that maybe we don't need these checks for FDW join paths, because we don't build parameterized paths for those yet. Now I think it would still be a good idea to have a way of handling that case, because somebody's likely going want to fix that /* XXX Consider parameterized paths for the join relation */ eventually, but I guess for the back-branches just setting epq_path = NULL instead of calling GetExistingLocalJoinPath() might be the way to go... assuming that your contention that this won't break anything is indeed correct. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company