Peter Eisentraut wrote:
Andrew Dunstan wrote:
But the reasons that applied to PL/Java (masses of non-C code was the
main one) probably don't apply in these 2 cases.

I don't think it's the amount of non-C code; it's the amount of code that no one understands. Plus, an argument *for* inclusion was build farm coverage, which I understand will be solved in a different way, applicable to all external modules. Another argument was buzzword compliance, which doesn't apply to these two new candidates. So in summary, while I have not seen any valid reason for these inclusions, there continue to be some against it.

Ahh o.k. not to be argumentative but PHP is huge and RUby gets more then it fair share of press and articles written about it now.

Alot of those *enterprises* that used to use Java are migrating to PHP (why I really don't know but that isn't the point).

That being said, PLphp is currently a no-op and won't be able to be considered for 8.2 due to portability issues. However PLruby is a valid inclusion and would enhance our portfolio of pl languages nicely.

PLruby also has the benefit of not being repulsive to Perl or Python programmers (where is many perl and python guys really don't like the other ;)).


Joshua D. Drake


   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to