Re: inherit support for foreign tables

(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().

Thanks,

Best regards,
Etsuro Fujita

>
> On Mon, Jun 30, 2014 at 12:22 PM, 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:
>
> (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