From: | Jeremy Drake <pgsql(at)jdrake(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com> |
Subject: | Re: modules |
Date: | 2008-04-04 05:18:37 |
Message-ID: | Pine.BSO.4.64.0804032157210.24175@resin.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Thu, 3 Apr 2008, Peter Eisentraut wrote:
> Am Donnerstag, 3. April 2008 schrieb Andrew Dunstan:
> > If this were at all true we would not not have seen the complaints from
> > people along the lines of "My ISP won't install contrib". But we have,
> > and quite a number of times. We have concrete evidence that calling it
> > contrib actually works against us.
>
> ISPs also won't install additional Perl modules, for example. Yet, CPAN does
> exist successfully.
ISPs don't necessarily HAVE to install additional perl modules. If I have
my own home directory and shell access, I can run "perl Makefile.PL
PREFIX=/home/myuser/perlstuff", and just tweak PERL5LIB (or use lib) and I
can install modules without any superuser intervention.
This is where the CPAN comparison breaks down. I can install any perl
module I want (native perl or even XS/C modules) without superuser
privileges. With postgres, super user privileges are REQUIRED to install
any module, whatever it is called (contrib, modules, pgfoundry, gborg)...
IMHO, this is the Achilles heel of Postgres extensibility. Look at this
library of plugins out there that do all of these nifty things, and if you
can't find one that fits your needs, you can always write a little C code
to do the job exactly how you want. Too bad you can't use them if you
can't afford your own dedicated database server instance...
This was the most frustrating thing for me as a developer. I know that
there are all of these fine modules out there, and I even have a few of my
own. I have been spoiled by the extensibility of Postgres, only to have
it taken away when I want to move my databases from my own machine into
production on the hosting provider.
If I want to put geographical data in a database, I know PostGIS is out
there, but I can't install it. I could use cube/earthdistance, but I
can't install that either. So much for the geographical data. How about
text search? Nope, can't have that either, at least until 8.3 finds its
way into OpenBSD ports and the hosting provider gets around to installing
it. At least I have that to look forward to.
My opinion is, it doesn't matter what you call the modules/contrib stuff
if I can't use it, and I can't use it if it is not loaded in my
database, and I can't load it without superuser privileges.
--
Never put off till tomorrow what you can avoid all together.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-04-04 05:33:14 | Re: pg_dump ignoring without oids |
Previous Message | Greg Smith | 2008-04-04 05:02:13 | Re: simple update queries take a long time - postgres 8.3.1 |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-04-04 05:40:35 | Re: [HACKERS] ANALYZE getting dead tuple count hopelessly wrong |
Previous Message | Pavan Deolasee | 2008-04-04 04:31:31 | Re: [HACKERS] ANALYZE getting dead tuple count hopelessly wrong |