Re: Extensions User Design

Josh Berkus wrote:
>
>> - 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.
>
>

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.

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.

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.

cheers

andrew