Re: pgsql_fdw in contrib - Mailing list pgsql-hackers

2012/6/19 Merlin Moncure <mmoncure@gmail.com>:
> On Mon, Jun 18, 2012 at 11:01 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, Jun 18, 2012 at 12:24 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>> I can't help but wonder (having been down the contrib/core/extension
>>> road myself) if it isn't better to improve the facilities to register
>>> and search for qualified extensions (like Perl CPAN) so that people
>>> looking for code to improve their backends can find it.  That way,
>>> you're free to release/do xyz/abandon your project as you see fit
>>> without having to go through -hackers.  This should also remove a lot
>>> of the stigma with not being in core since if stock postgres
>>> installations can access the necessary modules via CREATE EXTENSION, I
>>> think it will make it easier for projects like this to get used with
>>> the additional benefit of decentralizing project management.
>>
>> Well, if you're the type that likes to install everything via RPMs
>> (and I am) then you wouldn't want this behavior, especially not
>> automagically.  It seems to open up a host of security risks, too: I
>> believe Tom has previously stated that Red Hat (and other distro)
>> packaging guidelines forbid packages from installing software in
>> places where they can then turn around and run it.  I suppose CPAN
>> must have some sort of exception to this policy, though, so maybe it's
>> not ironclad.
>
> Huh? CPAN is just one example -- PyPM for python, npm for node etc
> etc.  There is some distinction to that rule that is being missed so
> that it doesn't apply to cases like this -- probably that it is
> transacted by the user and/or requires su.
>
> I think your points are supporting mine: the vast majority of postgres
> administrators deal only with o/s packaged rpms and therefore with the
> status quo are unable to utilize any extension that is not packaged
> with contrib.  This means that there are two possible outcomes if you
> want to write an extension:
>
> 1) get accepted into core
> 2) never get used
>
> Given that running the gauntlet to #1 is not a particularly attractive
> option (or even possible) in many cases for various reasons it tends
> to discourage module development by 3rd parties.  There are several
> very high quality extensions that could get a lot more exposure...for
> example pl/sh.
>
> But anyways, if you're happy with pgsql_fdw (aside: i looked at it,
> and it's great!) in core, then by all means...
>
Let me push the pgsql_fdw in core from different perspective.

Right now, FDW is a feature that will take many enhancement in
the near future like join-pushdown, writable APIs and so on.
If we would not have a FDW extension in core that communicate
with actual RDBMS, instead of flat files, it makes our development
efforts more complex. Please assume a scenario people alwats
tries to submit two patches; one for the core, and the other for
a particular out-of-tree extension.
I believe it is reasonable choice to have a FDW for PostgreSQL
in core, rather than MySQL or Oracle. We can use this extension
to show how new feature works, whenever we try to extend FDW
APIs.

BTW, Hanada-san-
It seems to me the expected result of regression test was not
included in this patch. Please submit it again-

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>