Re: inherit support for foreign tables

On Mon, Jun 30, 2014 at 4:17 PM, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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(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
>>
>

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company