Re: plPHP and plRuby

Peter,

> 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.

The main reason for including PL/Ruby is that by whatever accident the Ruby
community is tending to choose PostgreSQL as their SQL-RDBMS of choice.
This is a tendency we'd like to encourage, and one way to do so is to
attract Ruby developers to the idea of putting Ruby logic into the
database. This also might have the effect of getting more Rails
developers to learn about real database architecture.

Secondly, I've been told Ruby has some nice features as a language that
make it a useful edition to our "stable" of procedural languages.
Hopefully the Ruby aficiandos will speak up an enumerate these.

On the other hand, if we include PL/Perl, Tcl and Python but exclude Ruby
from the main package we are effectively making a statement to Ruby users
that their language is inferior in our consideration.

And, as Andrew said, Buildfarm External Modules are not going to be added
next month.

However, the lack of a maintainer who is an active participant in the
community is a serious drawback ... probably even a fatal one. Josh, is
there a reason why the PL/Ruby hacker doesn't want to play with us?

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco