Re: inherit support for foreign tables - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: inherit support for foreign tables
Date
Msg-id 53B263A1.3060107@lab.ntt.co.jp
Whole thread Raw
In response to Re: inherit support for foreign tables  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: inherit support for foreign tables  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
(2014/07/01 16:04), Ashutosh Bapat wrote:
> On Tue, Jul 1, 2014 at 12:25 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp <mailto:fujita.etsuro@lab.ntt.co.jp>> wrote:

>     Maybe I'm missing something, but what's the point of using the
>     tlist, not reltargetlist?

> Compliance with other create_*scan_plan() functions. The tlist passed to
> those functions is sometimes preprocessed in create_scan_plan() and some
> of the function it calls. If we use reltargetlist directly, we loose
> that preprocessing. I have not see any of create_*scan_plan() fetch the
> targetlist directly from RelOptInfo. It is always the one supplied by
> build_path_tlist() or disuse_physical_tlist() (which in turn calls
> build_path_tlist()) or build_physical_tlist().

I've got the point.

As I said upthread, I'll work on calculating attr_needed for child rels, 
and I hope that that will eliminate your concern.

Thanks,

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Ronan Dunklau
Date:
Subject: Re: IMPORT FOREIGN SCHEMA statement
Next
From: Dean Rasheed
Date:
Subject: Re: RLS Design