Re: modules - Mailing list pgsql-hackers

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.