Re: pgsql_fdw, FDW for PostgreSQL server

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql_fdw, FDW for PostgreSQL server
Дата
Msg-id 7122.1329231021@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql_fdw, FDW for PostgreSQL server  (Shigeru Hanada <shigeru.hanada@gmail.com>)
Ответы Re: pgsql_fdw, FDW for PostgreSQL server  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список pgsql-hackers
Shigeru Hanada <shigeru.hanada@gmail.com> writes:
> (2012/02/14 17:40), Etsuro Fujita wrote:
>> As discussed at
>> that thread, it would have to change the PlanForeignScan API to let the
>> FDW generate multiple paths and dump them all to add_path instead of
>> returning a FdwPlan struct.

> Multiple valuable Paths for a scan of a foreign table by FDW, but
> changing PlanForeignScan to return list of FdwPlan in 9.2 seems too
> hasty.

I would really like to see that happen in 9.2, because the longer we let
that mistake live, the harder it will be to change.  More and more FDWs
are getting written.  I don't think it's that hard to do: we just have
to agree that PlanForeignScan should return void and call add_path for
itself, possibly more than once.  If we do that, I'm inclined to think
we cou;d get rid of the separate Node type FdwPlan, and just incorporate
"List *fdw_private" into ForeignPath and ForeignScan.

This does mean that FDWs will be a bit more tightly coupled to the
planner, because they'll have to change whenever we add new fields to
struct Path; but that is not really something that happens often.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.2] LEAKPROOF attribute of FUNCTION (Re: [v9.2] Fix Leaky View Problem)
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: SSI rw-conflicts and 2PC