On Mon, Jun 30, 2014 at 4:17 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
> (2014/06/30 17:47), Ashutosh Bapat wrote: > >> 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. > > Thanks, > > Best regards, > Etsuro Fujita > > >> On Mon, Jun 30, 2014 at 12:22 PM, Etsuro Fujita >> <fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> >> (2014/06/24 16:30), Etsuro Fujita wrote: >> >> (2014/06/23 18:35), Ashutosh Bapat wrote: >> >> >> 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
