On Fri, Aug 3, 2018 at 10:07 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Aug 2, 2018 at 4:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Now, that's a bit of a problem for postgres_fdw, because it seems to >>> insist on injecting WRVs even when the query text does not require any. >>> Why is that, and can't we get rid of it? > >> I don't quite know what you mean here -- postgres_fdw does use >> whole-row vars for EPQ handling, which may be what you're thinking >> about. > > As far as I can see from the example that started this thread, > postgres_fdw injects WRVs into a PWJ whether or not the query involves > FOR UPDATE; that's why this bug is reproducible in a query without FOR > UPDATE. But we shouldn't need any EPQ support in that case.
I might be missing something, but the original reproducer involves a FOR UPDATE clause, and the expected regression test output in postgres_fdw.out appears to show a whole-row var in the foreign scan's target list only in those examples where a locking clause is present. >> Honestly, I'm pretty impressed that we have added not one but two >> members to the RelOptKind enum without as little collateral damage as >> there has been. > > Color me a bit more skeptical about the bug density in that, given > that enable_partitionwise_join is off by default; that means you're > not getting a lot of testing. You're hard to please. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
