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