Re: Extensions User Design - Mailing list 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