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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org