I vote to see the contrib/xml2's xslt_process() build-in function (only xslt_process) moved into PostgreSQL core.
---- Database servers can offer some "load balancing" with another CPUs, like a PHP server... I have in mind some main examples: * If database server not process XSLT, the *balance* is lost (for PHP processing DOM and XSLT). * If database server not process XSLT, a lot of *traffic* and not-elegant * code* is necessary. * If a "XML framework" is developed for "SQL-side", like Oracle-APEX, a lot of *extra-workaround* is necessary to build the framework (with external XML processing). * ... Another big problem is the *lack of xQuery*, them the *internal processing of XSLT is a important workaround*. Several "serious XML projects" are being lost to Oracle, only because of this lack of xQuey and XSLT support. PS: the main XPath libraries implements also XSLT; PostgreSQL core have XPath, to add XSLT is only a little more.