On Mon, Jun 18, 2012 at 11:01 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jun 18, 2012 at 12:24 PM, Merlin Moncure <mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers