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