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


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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to