On Sat, Apr 27, 2019 at 2:10 AM Tom Lane <tgl@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
