Thread: 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