> > One thing tricky is "peusdo projection" which is done by > > deparseProjectionSql for whole-row reference. This is done by put the > > query string in FROM subquery and add whole-row reference in outer > > SELECT clause. This is done by ExecProjection in 9.4 and older, but > > we need to do this in postgres_fdw because ExecProjection is not > > called any more. > > What commit changed this? > It seems to me the nature of whole-row reference, not a flaw of ExecProject().
In case of base relation scan, whole-row reference is transformed to ExecEvalWholeRowVar, then executed during ExecProject(). It constructs a record datum according to the TupleDesc of the relation being in scan. On the other hands, foreign-join also looks like a scan on relation that is result set of remote join, its record type is defined in the fdw_scan_tlist. However, it may contain values come from multiple relations, so it is not intended behavior if whole-row reference constructs a record datum that contains all the attributes in the result- set. In this context, whole-row reference shall contain all the attributes of the "base" relation. Only FDW driver can know, and ensure all the attributes to construct whole-row reference are fetched from remote side. Hanada-san, could you correct me, if I misunderstood above your explanation? Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
