Re: pgsql_fdw, FDW for PostgreSQL server

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Date: 2011-10-26 14:57:48
Message-ID: CADyhKSWKKxafOTO2rk=oOjJ3QsVuBfNgMS+0+gb62JJ=JOM_sg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/10/26 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 2011/10/26 Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>:
>> (2011/10/25 19:15), Magnus Hagander wrote:
>>> 2011/10/25 Shigeru Hanada<shigeru(dot)hanada(at)gmail(dot)com>:
>>>> I'd like to propose pgsql_fdw, FDW for external PostgreSQL server, as a
>>>> contrib module.  I think that this module would be the basis of further
>>>> SQL/MED development for core, e.g. join-push-down and ANALYZE support.
>>>
>>> I have not looked at the code itself, but I wonder if we shouldn't
>>> consider making this a part of core-proper, not just a contrib module.
>>> The fact that it isn't *already* available in core surprises a lot of
>>> people...
>>
>> Do you mean that pgsql_fdw should be a built-in extension like plpgsql
>> so that it's available just after initdb?  It would be accomplished with
>> some more changes:
>>
>> * Move pgsql_fdw into core, say src/backend/foreign/libpgsql_fdw, and
>> install dynamically loadable module during "make install" for core.  The
>> pgsql_fdw_handler function can't be included into core binary because we
>> must avoid liking libpq with server binary directly.  This method is
>> also used for libwalreceiver of replication module.
>> * Create pgsql_fdw extension during initdb invocation, like plpgsql.
>>
>> These are not trivial, but not difficult so much.  However, I think
>> contrib would be the appropriate place for pgsql_fdw because it's
>> (relatively) special feature.
>
> I agree.  pgsql_fdw will be a nice feature, but there's no reason to
> think that everyone will want it installed by default, and there are
> some security reasons to think that they might not.  On the flip side,
> pushing it out of contrib and onto pgfoundry or whatever makes it
> unnecessarily difficult to install, and not as many people will
> benefit from it.  So contrib seems exactly right to me.
>
I also agree. The pgsql_fdw will be worthful to locate in the main tree
as a contrib module. It will give us clear opportunity to test new
features of FDW using RDBMS characteristics; such as join-push-down.
However, it should be a separated discussion whether it shall be installed
by the default.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Redekop 2011-10-26 15:36:56 Re: Hot Backup with rsync fails at pg_clog if under load
Previous Message Chris Redekop 2011-10-26 14:51:30 Re: Hot Backup with rsync fails at pg_clog if under load