Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?

On Thu, Jul 23, 2015 at 8:27 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> A dark side is, as discussed in this thread, complexity of EvalPlanQual.
> RefetchForeignRow() returns a tuple based on foreign table definition,
> on the other hands, whole-row var points a tuple based on fdw_scan_tlist
> if exists.
> An alternative host-only plan-node and relevant expression will be
> constructed towards the definition of base foreign-table. So, we need to
> transform the tuple to the layout based on foreign table definition if
> we allow fdw_scan_tlist with scanrelid > 0.
>
> However, I'm skeptical whether this solution is valid for long term.
> Once we support to push down expensive expression in target-list to
> remote side, fdw_scan_tlist will contain expression node rather than
> simple Var node. In this case, it is not obvious to reproduce a tuple
> according to the foreign table definition from a record based on the
> fdw_scan_tlist.

I don't think we can realistically make a decision that pushing down
target list expressions to the remote side is forever off the table.

Is the problem here that it's not *possible* for an FDW to do the
right thing, or just that it might be difficult to code in practice?
I'm fuzzy on why this isn't just a matter of having
RefetchForeignRow() return a row with the correct tuple descriptor.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company