Le 24 juin 09 à 22:43, Josh Berkus a écrit :
... most of. Some of the things in contrib are largely examples or
hacker tools; if we don't cover those it's OK.
Good to know.
We need versioning support right now, separate from any UIP support.
Otherwise the dump/reload won't work.
You want pg_dump to issue an INSTALL EXTENSION command with specific
version needed, right?
- 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.
Good for me :)
- custom variables?
Don't we have these already?
It's a matter of exposing a way to attach them to a specific
extension. Are GUCs a possible element of pg_depend?
- 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.
That'd make my day.
- 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.
It'd still deprecate contrib/, which could maybe become examples/?
- 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.
I hope it'll get simple enough, yes, as simple as current PGXS modules
from source are:
- cvs up or wget
- tar xzf ... && cd ...
- make install
- psql -f ... mydb
begin;
install extension foo with search_path = foo;
Needs install file location:
No, extensions meta-data are in foo.sql and already loaded into the
database by the time you get to INSTALL EXTENSION. That's a part I
like because it makes it simple to handle meta-data and to declare
that SQL objects from the script are part of the extension.
I also dislike the CREATE EXTENSION which is not INSTALLing it...
maybe a WITH INSTALL syntax option could do?
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.
PGXS has it covered, and we're not yet there, but I'm thinking PGXS
should be a pre requisite of the extension facility as far as
extensions authors are concerned. Then packagers will make it so that
users won't typically face those details.
Also, this means that we'll want to make sure that PGXS is included
in all existing packages of PostgresQL. Is it?
Only those packages you want to have extension support from source ;)
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
