I checked that it's reporting the right tableoid now.
Thank you for the check.
BTW, why aren't you using the tlist passed to this function? I guess create_scan_plan() passes tlist after processing it, so that should be used rather than rel->reltargetlist.
I think that that would be maybe OK, but I think that it would not be efficient to use the list to compute attrs_used, because the tlist would have more information than rel->reltargetlist in cases where the tlist is build through build_physical_tlist().
In that case, we can call build_relation_tlist() for foreign tables.
Selecting tableoid on parent causes an error, "ERROR: cannot extract system attribute from virtual tuple". The foreign table has an OID which can be reported as tableoid for the rows coming from that foreign table. Do we want to do that?
No. I think it's a bug. I'll fix it.
Done. I think this is because create_foreignscan_plan() makes reference to attr_needed, which isn't computed for inheritance children. To aboid this, I've modified create_foreignscan_plan() to see reltargetlist and baserestrictinfo, instead of attr_needed. Please find attached an updated version of the patch.
Sorry for the delay.
Best regards, Etsuro Fujita
-- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
