Re: Odd system-column handling in postgres_fdw join pushdown patch

On 2016/03/22 14:54, Ashutosh Bapat wrote:
> On Tue, Mar 22, 2016 at 8:03 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp <mailto:fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>> wrote:
> OK, I'll modify the patch so that the join is pushed down even if
> any of xmins, xmaxs, cmins, and cmaxs are requested. Do you think
> which one should set values for these as well as tableoids,
> postgres_fdw or core?

> Earlier in this mail chain, I suggested that the core should take care
> of storing the values for these columns. But instead, I think, core
> should provide functions which can be used by FDWs, if they want, to
> return values for those columns. Something like Datum
> get_syscol_value(RelOptInfo/Relation, attno). The function will return
> Datum 0 for most of the columns and table's OID for tableoid. My 0.02.

What I had in mind was (1) create_foreignscan_plan would create Lists
from the ForeignScan's fdw_scan_tlist: (a) indexes/OID values of
tableoids in fdw_scan_tlist, and (b) indexes of xids and cids in
fdw_scan_tlist, and then (2) ForeignNext would set the OID values for
the tableoid columns in the scan tuple, using the Lists (a), and
appropriate values (0 or something) for the xid and cid columns in the
scan tuple, using the List (b).

Best regards,
Etsuro Fujita