Re: Extensions User Design

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extensions User Design
Date: 2009-06-24 21:12:53
Message-ID: AD0B29B9-E399-445C-A84C-865047959588@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2009-06-24 21:21:44 Re: Extensions User Design
Previous Message Andrew Dunstan 2009-06-24 21:07:32 Re: Extensions User Design