On Thu, Jul 23, 2015 at 8:27 PM, Kouhei Kaigai <kai...@ak.jp.nec.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
