Thread: future of contrib/xml2 and xslt processing

contrib/xml2 has been claimed to be deprecated since PostgreSQL 8.3.  I
took a look through the functions it offers and perhaps with xmltable
now being available, they could all be replaced using built-in
functions, perhaps with some small tweaking.

But we don't have any replacement lined up for the XSLT processing
function xslt_process.  What should we do with that, assuming that we
eventually want to remove contrib/xml2 altogether?

1. Just remove it, leaving users to find other solutions.  (PL/P* can
probably fill the gap.)

2. Create a new extension contrib/xslt, move the implementation there.
(Optionally, have contrib/xml2 depend on this new extension if it is not
ready to be removed.)

3. Add XSLT functionality to core (unlikely).

Thoughts?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> contrib/xml2 has been claimed to be deprecated since PostgreSQL 8.3.  I
> took a look through the functions it offers and perhaps with xmltable
> now being available, they could all be replaced using built-in
> functions, perhaps with some small tweaking.

> But we don't have any replacement lined up for the XSLT processing
> function xslt_process.  What should we do with that, assuming that we
> eventually want to remove contrib/xml2 altogether?

> 1. Just remove it, leaving users to find other solutions.  (PL/P* can
> probably fill the gap.)

> 2. Create a new extension contrib/xslt, move the implementation there.
> (Optionally, have contrib/xml2 depend on this new extension if it is not
> ready to be removed.)

> 3. Add XSLT functionality to core (unlikely).

Option 2 seems like useless churn; we'd still have the same
not-very-high-quality code, just moved around.

I agree that moving the libxslt dependency into core isn't real
attractive either.

I suspect that the realistic alternatives are either option 1
or option 0: do nothing.

            regards, tom lane

Hi,

On 2018-05-22 14:38:32 -0400, Peter Eisentraut wrote:
> 1. Just remove it, leaving users to find other solutions.  (PL/P* can
> probably fill the gap.)

I don't have access to the code anymore, but a good number of past
customers and employers of mine relied on xslt.  I think we'd get some
pushback for this.

Greetings,

Andres Freund