Re: voting to the xslt_process() need - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: voting to the xslt_process() need
Date
Msg-id 4EB81549.70109@dunslane.net
Whole thread Raw
In response to voting to the xslt_process() need  (Peter Padua Krauss <ppkrauss@gmail.com>)
Responses Re: voting to the xslt_process() need
List pgsql-hackers



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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: type privileges and default privileges
Next
From: Simon Riggs
Date:
Subject: Re: synchronous commit vs. hint bits