Re: Extensions User Design - Mailing list pgsql-hackers
From | Josh Berkus |
---|---|
Subject | Re: Extensions User Design |
Date | |
Msg-id | 4A428FF8.3070108@agliodbs.com Whole thread Raw |
In response to | Extensions User Design (Dimitri Fontaine <dfontaine@hi-media.com>) |
Responses |
Re: Extensions User Design
(Andrew Dunstan <andrew@dunslane.net>)
Re: Extensions User Design (Dimitri Fontaine <dfontaine@hi-media.com>) Re: Extensions User Design (Dimitri Fontaine <dfontaine@hi-media.com>) Re: Extensions User Design (Dave Page <dpage@pgadmin.org>) Re: Extensions User Design (Dimitri Fontaine <dfontaine@hi-media.com>) |
List | pgsql-hackers |
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
pgsql-hackers by date: