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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
