Re: inherit support for foreign tables
От | Etsuro Fujita |
---|---|
Тема | Re: inherit support for foreign tables |
Дата | |
Msg-id | 53B263A1.3060107@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: inherit support for foreign tables (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: inherit support for foreign tables
|
Список | 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 по дате отправления: