On Sat, Apr 27, 2019 at 2:10 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > (2019/04/26 3:24), Tom Lane wrote: > >> If we do leave it like this, then the only way for postgres_fdw to > >> avoid trouble is to not have any entries in fdw_exprs that exactly > >> match entries in fdw_scan_tlist. So that pretty much devolves back > >> to what I said before: don't ship values to the far end that are > >> just going to be fed back as-is. But now it's a correctness > >> requirement not just an optimization.
> Well, the releases are coming up fast, so I spent some time on this. > If we don't want to change what the core code does with fdw_exprs, > I think the only way to fix it is to hack postgres_fdw so that it > won't generate plans involving the problematic case. Seems reasonable. > See attached. I read the patch. It looks good to me. I didn't test it, though. > We end up with slightly weird-looking plans if the troublesome Param > is actually a GROUP BY expression, but if it's not, I think things > are fine. Maybe we could do something smarter about the GROUP BY case, > but it seems weird enough to maybe not be worth additional trouble. Agreed. Thanks for working on this! Best regards, Etsuro Fujita
