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.

Reply via email to