Andrew Dunstan wrote:
>> I think it'd be especially cool if one could one-day have a command
>>
>>   pg_install_module  [modulename] -d [databasename]
> 
> 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.

Sure - but the benefits of standardizing installers for optional
components seems to apply the same for both.

> We do in fact have some support for building / installing some modules 
> in a standard way. It's called pgxs and it is used by quite a number of 
> existing modules.

Cool.  Seems to handle at least quite a bit of the building part of
standardized modules.

> One thing that might be worth looking at is an install command at the 
> SQL level, so the "INSTALL foo" would run the install script for the foo 
> module in the current database, assuming it's in the standard location.

I'm guessing that this would be harder to add various
options (install/ignore dependancies ; specify a different source
web site) that a standard installer would like to have.


> We don't have a central repository of non-standard modules, like CPAN, 
> and so of course no facility for fetching / building / installing them.

Seems that could easily be improved in a number of ways.

   * The installer could specify the source.  For example
       pg_install_module postgis -source http://www.refractions.net
     in exactly the same way ruby uses
       gem install rails –source http://gems.rubyonrails.org

   * pgfoundry could provide a repository of installable modules
     for projects hosted there.

   * perhaps pgfoundry could even have a section where it points
     to installers on third party sites?

> Not all modules fit a single pattern, either. There are addon languages, 
> types, and function libraries, as we all as utilities that are not 
> installed in the database at all.

Agreed.  Such a mechanism would only really apply for things
that are installed in the database.   But from an end user's
point of view, installing functions, index types, languages,
data types, etc all see to fit the "pg_install postgis -d mydb",
"pg_install pl_ruby -d mydb", etc. pattern pretty well.

> Finally, setting up modules so they can be built for Windows, especially 
> using MSVC, will probably be quite a challenge.

Indeed.   Seems ruby gems give you the option of installing a "ruby"
version or a "windows" version that I'm guessing has pre-compiled
object files.

> So if someone wants to make a start on any of this I'm sure we would all 
> listen up.
I'm happy to try, though might need pointing in the right directions.

In response to

• Re: modules at 2008-04-03 00:15:49 from Andrew Dunstan

Responses

• Re: modules at 2008-04-03 09:11:29 from Tom Dunstan

pgsql-hackers by date

Next:	From: D'Arcy J.M. Cain	Date: 2008-04-03 00:55:52
	Subject: Re: modules
Previous:	From: Bruce Momjian	Date: 2008-04-03 00:41:56
	Subject: Re: printTable API (was: Show INHERIT in \du)

pgsql-general by date

Next:	From: Andreas	Date: 2008-04-03 00:44:23
	Subject: PG 8.3.x doesn't get build
Previous:	From: Greg Sabino Mullane	Date: 2008-04-03 00:22:30
	Subject: Re: Proper Way to Disable Triggers