Re: plPHP and plRuby - Mailing list pgsql-hackers

Marc G. Fournier wrote:
>> Actually it would be nice to have the not-included PLs present in
>> src/pl/ as their own directories with a README.TXT containing fetch and
>> build instructions
>>
>> So we would have
>>
>> src/pl/plphp/README.TXT
>> src/pl/pljava/README.TXT
>> src/pl/plj/README.TXT
>>
>> and anybody looking for pl-s would find the info in a logical place
> 
> *That* idea I like ...
>
ISTM that a clear strategy for how to deal with core, contrib, add-ons, etc. is long overdue 
and that's the reason why these discussions pop up over and over again. The question "What 
are the criterion's for core inclusion?" has not yet been answered. I though PL/Java 
fulfilled those criterion's but a new threshold for the #lines of code and a concern for 
code in unmaintainable language made it impossible.

The result of an unclear strategy can be perceived as somewhat unjust. There seem to be a 
very unanimous consensus that PL/pgsql belongs in core. Large object support, free text 
search and some others also receive support by everyone. These add-ons clearly belong where 
they are. The "historical reasons" to continuously include others are, IMHO, not so obvious 
and the result undoubtedly creates first- and second class citizens in the module flora. The 
split doesn't correlate very well with feature richness or popularity.

I have a suggestion that might help clearing things up a bit :-)

A couple of specialized teams need to be established (or rather, formalized since they 
already exists to some extent) that can be thought of as "core subsidiary's". The idea is 
that such a team would take on the maintenance of one specialized area of PostgreSQL. Java, 
for instance, is such an area. PostgreSQL has a huge number of Java users. They all use the 
JDBC driver and a few use PL/Java. There's been talk about Eclipse tool support and some 
will have an interest in XA-compliance in order to gain JTA support, etc. Today, it's 
scattered all over the place. Other subsidiary teams should be formed around odbc (or .net 
perhaps), php, ruby, replication/clustering, etc. to take control over those areas.

A very important part of my suggestion is that for the normal user, it would appear that 
what a "core subsidiary" team contribute really is *part of* the database proper and not 
something maintained by a third-party contributor or commercial vendor.

The team would maintain their own website (although all layout would be centralized), source 
code control system, mailing list etc. but they would share a lot more of the PostgreSQL 
infrastructure then what is shared today. Important things would be:

- Documentation. Inclusion of a subsidiary module should mean that some chapters are added 
(automatically) to the user manual.
- Build farm support.
- Packaging and downloads
- Server infrastructure
- Seamless navigation from the PostgreSQL main web-site.

PgFoundry would live on like today, targeted on third-party modules and serving as an 
incubator for modules that aim to be included in core or into one of its subsidiaries.

Kind Regards,
Thomas Hallgren