Re: PostgreSQL is a forkbomb...
This is incorrect, for several reasons. First, this specific example is not a fork bomb example -- if all a stored procedure does execute a query, another connection to the database is not made, and thus another process is not forked. While I suppose you could write a function using C that used libpq to open another DB connection, it would be pointless.
Second (and more importantly), trying to make a database secure if you allow users to execute arbitrary SQL is pointless (for example: disable the GEQO, execute a 20 table join query from 10 concurrent clients, and watch PostgreSQL eat up gigabytes of RAM and many minutes of CPU time). You simply cannot allow untrusted users to execute arbitrary SQL. It's even more dangerous to allow them to define functions; functions defined in C can trivially crash the backend. You might be able to get a modicum of security by using rlimit-style restrictions on the resources that PostgreSQL can use, but that's not a complete solution.
relationship with Xerces?
How does this release compare with Apache Xerces? There are IBM developers working on Xerces, and IIRC, source code from IBM was used as the foundation for Xerces. Xerces also seems to support more XML-related standards, and has a much more liberal license.
Are there any reasons to choose this product over Xerces?