Re: pgsql_fdw in contrib

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: pgsql_fdw in contrib
Дата
Msg-id CAHyXU0xEOYq4-MGib5aAsCDpwQTtJzNs2BL5w2yfNNZJ3Yh-yQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgsql_fdw in contrib  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pgsql_fdw in contrib  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Список pgsql-hackers
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...

merlin


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: use of int4/int32 in C code
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Allow WAL information to recover corrupted pg_controldata