Re: plPHP and plRuby

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