From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: future of contrib/xml2 and xslt processing |
Date: | 2018-05-22 18:46:52 |
Message-ID: | 14464.1527014812@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-05-22 18:47:01 | Re: found xmin from before relfrozenxid on pg_catalog.pg_authid |
Previous Message | Peter Eisentraut | 2018-05-22 18:38:32 | future of contrib/xml2 and xslt processing |