2011/10/26 Shigeru Hanada <shigeru.hanada@gmail.com>:
> (2011/10/25 19:15), Magnus Hagander wrote:
>> 2011/10/25 Shigeru Hanada<shigeru.hanada@gmail.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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
