voting to the xslt_process() need

On 11/07/2011 12:10 PM, Peter Padua Krauss wrote:

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.

We don't really have a "voting" process like you seem to think. If you
want something to happen then your best bet is to devote resources to
making it happen. This could be either effort in the way of patches, or
sponsorship money for someone who is capable of making it happen, for
example.

Please also see earlier discussions of these items in the mailing list.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Please also see earlier discussions of these items in the mailing list.

Yes. It's very unlikely that we'll accept a patch that just moves
xslt_process into core without doing anything about its definitional
and implementation shortcomings. See for instance

http://archives.postgresql.org/pgsql-hackers/2011-02/msg01878.php

regards, tom lane