Re: Extensions User Design

Le 24 juin 09 à 23:07, Andrew Dunstan a écrit :
> Actually, I think we should be like Perl here. There is a list of
> standard modules that comes with the base Perl distro, and then
> there are addons, such as you find on CPAN. File::Find is an example
> of a standard module, DBD::Pg is an example of an addon.

Agreed.

> Quite apart from anything else, having some extensions maintained by
> core will help in validating the extension mechanism.
>
> Good candidates for core-supported extensions would include
> PL{Perl,Python,Tcl}, pgcrypto and hstore, IMNSHO. Between them they
> illustrate a number of the major extension paradigms.

That read as a good start, even if I'd maybe like to add ltree and
plproxy, maybe more for convenience than anything else.

> Beyond standard extensions, I'm not sure we need a committee to
> "approve" extensions. Does Perl have such an animal? I'm fairly wary
> of creating new decision-making bureaucracies.

I think what Josh is referring too is to have the standard core
extensions whose aim is to show how extensions work, provided
maintained examples etc, *and* a community list of useful extensions
(temporal, prefix, oracfe, pgtap, you name it) that users will
probably want to find.
This list will have to provide some more information, ones that are
implicit within the first group: is the software maintained, by whom,
is it production ready, feature complete, is it a community endorsed
product, etc.

While I'm all for avoiding bureaucracy, I'd like us to be able to show
how rich and trustworthy the PostgreSQL overall solution and community
is. Core-supported extensions won't allow that on their own.

Regards,
--
dim