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.etsuro@lab.ntt.co.jp <mailto:fujita.etsuro@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