Re: Extensions User Design

Dim,

> The contenders are extension, module, bundle and package. My vote is
> extension.

+1 on "extension".

> We're not trying to be feature complete on first round.
>
> * must have
>
>
>   - support for all what you find in contrib/ for 8.4 (covered already?)

... most of. Some of the things in contrib are largely examples or 
hacker tools; if we don't cover those it's OK.

> * would be great (target later commit fest)
>
>   - versioning support with upgrade in place facility (hooks?)

We need versioning support right now, separate from any UIP support. 
Otherwise the dump/reload won't work.

>   - supporting more than one version of the same module installed in the same
>     time, possibly (I suppose always but...) in different schemas

We can put this off until we have a use-case for it.  I can't imagine one.

>   - custom variables?

Don't we have these already?

>   - PostGIS complete support, with user data dependancy, even if an
>     extensible typmod system would certainly solve this problem in a better
>     place. Maybe someone will come up with another existing extension sharing
>     the problem and not the typmod solution?

Or we just fix that issue for 8.5.

>   - a core team approved list of extensions (replacing contribs, maybe adding
>     to it), where approved means code has been reviewed and the only reason
>     why it's not in the core itself is that core team feels that it's not
>     part of a RDBMS per-se, or feel like the code should be maintained and
>     released separately until it gets some more field exposure... (think
>     plproxy).

The core team isn't appropriate for this.  We'd start a new 
committee/list somewhere instead, and it would be part of the same 
effort which produces a "recommended" list of extensions and drivers for 
packagers.

>   - CPAN or ports like infrastructure for auto downloading a more or less
>     prepared "bundle", place it at the right place on the filesystem and
>     install it in the database(s) of choice

This may not be necessary if simple download-unzip-and-install is simple 
enough.

>   - complex support for ad-hoc bootstrap of uncommon modules such as pljava
>
>   - dependancy graph solving and automatic installation, with depends,
>     recommends and suggest sections and with rules/setup to choose what to
>     pull in by default...

Uh-huh.  That'll be the day ...

> === installing and removing an extension
>
>    begin;
>    install extension foo with search_path = foo;

Needs install file location:

INSTALL EXTENSION foo FROM '~/downloads/foo' WITH search_path = 'foo';

> == OS Filesystem Interaction
>
> PostgreSQL already provides standard paths where to install extensions by
> means of PGXS, and distribution packagers have been able to adapt those. We
> should just stick with this, meaning the problem is solved.

I think that the user should be able to put the extension file download 
anywhere in their filesystem, and on install PostgreSQL should copy the 
files to the appropriate place.  That is, they shouldn't have to first 
copy the files to /pg_source_dir/contrib/.  Maybe you had that covered, 
but I didn't see it explicitly.

Also, this means that we'll want to make sure that PGXS is included in 
all existing packages of PostgresQL.  Is it?

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com