This seems to have descended into a "my programming language is better
than your programming language" war, which has ceased to be
interesting, much less illuminating to the problem at hand.
There are two questions, I perceive, critical to making decisions
about what goes into the core. While I'm not a contributing developer,
I've worked with PostgreSQL since it was still Stonebraker's child and
still use Postquel, and have rolled it inot a lot of production
situations, so I'm going to speak from that perspective.
1) More isn't better.
2) What the *MARKET* cares about is PL/PGSQL and PL/Java.
I have the utmost detestful view of Java, but that's what it is. I
don't write my stored-procedures in Java, I write them in PL/PGSQL
because it is familiar to those who have to maintain the database,
which in my situation is often not who is maintaining the "front end"
code which many other languages are so happy for.
Personally, I think pulling PL/Java in, and throwing the rest out, is
a great idea. Let them mature seperately, and keep the perenial
language wars out of the core. What is in the core is a decision made
on a couple of points:
1) What helps Postgresql in the "market," such that it is.
2) What would the core team be willing to take ownership of because of
#1, even if the existing supports disappeared.
As someone who has been writing in Python since 1994, I like the
language, and we could have all sorts of discussions about language
idioms and safety, and the perception of each, but neither have
anything to do with the decision at hand.
Axes should be put away, and people should decide what is critical to
the market perception of the database, and as much as I hate to admit
it, Java is 1000x more important than Ruby, Perl, Python and Tcl
combined, when it comes to SELLING the use of Postgresql in a formal
organization. Outside that scenerio, why does it matter? Open source
"geeks" will download whatever to make it work, and bundling and non
bundling have nothing to do with their "decision" process.
Chris
--
| Christopher Petrilli
| petrilli@gmail.com
