Ron Mayer wrote:
> Andrew Dunstan wrote:
>> Tom Lane wrote:
>>> as having better system support for packages or modules or whatever
>>> you want to call them; and maybe we also need some marketing-type....
>>
>> ...re-raise the question of getting rid of contrib...
>> "The PostgreSQL Standard Modules".
>
> While renaming, could we go one step further and come up with a
> clear definition of what it takes for something to qualify as
> a module? In particular I think standardizing the installation
> would go a long way to letting packagers automate the installation
> of modules from pgfoundry.
>
> 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.
>
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.
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.
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.
We don't have a central repository of non-standard modules, like CPAN,
and so of course no facility for fetching / building / installing them.
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.
Finally, setting up modules so they can be built for Windows, especially
using MSVC, will probably be quite a challenge.
So if someone wants to make a start on any of this I'm sure we would all
listen up.
cheers
andrew
