Re: modules

On Thu, Apr 3, 2008 at 9:17 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> > It's hard to see ISPs who won't install contrib from installing
> > ${random module} from the big bad internet as has been discussed in
> > this thread, but who knows?
>
> Sure it is. The very word contrib brings about ideas of things like:
>
> Unstable, Cooker, unofficial.

Point taken, and I completely agree. Part of the problem is that we
have explicitly encouraged this perception, ie "it's in contrib so the
barrier to entry is lower". That may not be the case anymore, or it
may just be that the bar is really really high for non-contrib stuff
vs other projects. Whatever the actual case is, I agree that the name
is unfortunate.

When I wrote the above I was thinking about it from the other way
around: doing a cpan or gem install of some random module seems even
less safe to me, but maybe I'm just revealing confidence in pgsql or
fear of some cpan code etc that ISPs don't share.

> This would install all the modules but not enable them in the database
> itself (of course). This could also be extended to the pls so that we
> have exactly one mechanism to control those options as well.
>
> ./configure --enable-module=pgcrypto --enable-module=plperl

That's basically where I was heading, although I took it a step
further: why not build and install all possible modules by default, if
we think they're up to quality?

One answer is: what do you do if some required library isn't
available? Do you fail with an error message or just don't build that
module? I don't like the idea of e.g. accidentally and silently not
installing pl/perl just because the sysadmin hadn't installed their
perl-devel package or whatever.

--enable-module=ALL could be pretty good, though, especially if it
build pl/perl etc that most sysadmins will want to install but do so
in less configure args. :)

Cheers

Tom