Re: modules - Mailing list pgsql-hackers

From D'Arcy J.M. Cain
Subject Re: modules
Date
Msg-id 20080402205552.3654fafa.darcy@druid.net
Whole thread Raw
In response to Re: modules  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: modules  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
List pgsql-hackers
On Wed, 02 Apr 2008 20:15:49 -0400
Andrew Dunstan <andrew@dunslane.net> wrote:
> > I think it'd be especially cool if one could one-day have a command
> >
> >   pg_install_module  [modulename] -d [databasename]
> >
> > and it would magically get (or verify that it had) the latest
> > version from pgfoundry; compile it (if needed) and install it
> > in the specified database.
> >
> > The closest analogy to what I'm thinking is the perl CPAN or ruby gems.

Check out NetBSD pkgsrc as a model.  It is very flexible.  One nice
thing would be the ability to specify where the packages are rather
than always insisting that they be on pgfoundry.

> Yes, and the CPAN analogy that has been in several minds, but it only 
> goes so far. Perl and Ruby are languages - Postgres is a very different 
> animal.

So the underlying struture needs to keep that in mind.  Overall though
I don't think that what is being installed to changes much.  The basics
remain the same - define the package with latest version, download if
necessary,check that the source package is the correct, tested one,
build, install, register.

There are some special considerations for PostgreSQL but I think that
the fact that there are unsolved problems shouldn't stop us from
solving them.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.


pgsql-hackers by date:

Previous
From: Ron Mayer
Date:
Subject: Re: modules
Next
From: Bruce Momjian
Date:
Subject: Re: Patch for pg_dump (function dumps)