Prev: plperl compiler warning
Next: [HACKERS] returning array in a field together with other types
From: Andrew Dunstan on 28 Jan 2010 16:18



Robert Haas wrote:
> There has been some more discussion lately of problems caused by contrib/xml2.
>
> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00251.php
> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00198.php
>
> I think we need to either (1) fix the bugs and update the
> documentation to remove the statement that this will be removed or (2)
> actually remove it. Nobody seems interested in #1, so PFA a patch to
> do #2. It also rips out all the libxslt stuff, which seems to exist
> only for the purpose of supporting contrib/xml2.
>

The problem is that there are people who use the XSLT and xpath_table
stuff on text data and so don't run into these bugs.

I agree it's a mess but I don't think just abandoning the functionality
is a good idea.

cheers

andrew





--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Mike Rylander on 28 Jan 2010 16:44
On Thu, Jan 28, 2010 at 4:18 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote:
>
> Robert Haas wrote:
>>
>> There has been some more discussion lately of problems caused by
>> contrib/xml2.
>>
>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00251.php
>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00198.php
>>
>> I think we need to either (1) fix the bugs and update the
>> documentation to remove the statement that this will be removed or (2)
>> actually remove it.  Nobody seems interested in #1, so PFA a patch to
>> do #2.  It also rips out all the libxslt stuff, which seems to exist
>> only for the purpose of supporting contrib/xml2.
>
> The problem is that there are people who use the XSLT and xpath_table stuff
> on text data and so don't run into these bugs.
>
> I agree it's a mess but I don't think just abandoning the functionality is a
> good idea.

I'm one of those people. :)

Expecting to see contrib/xml2 go away at some point, possibly without
replacements for xslt_process and xpath_table, I've been working on
some plpgsql and plperlu work-alikes targeted at TEXT columns, as the
xml2 versions do. I hope these (attached) will be of some help to
others. Note, these are not the exact functions I use, they are
lightly edited to remove the use of wrappers I've created to paper
over the transition from xpath_nodeset() to core XPATH().

--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: miker(a)esilibrary.com
| web: http://www.esilibrary.com
From: Tom Lane on 28 Jan 2010 17:41
Andrew Dunstan <andrew(a)dunslane.net> writes:
> Robert Haas wrote:
>> I think we need to either (1) fix the bugs and update the
>> documentation to remove the statement that this will be removed or (2)
>> actually remove it.

> I agree it's a mess but I don't think just abandoning the functionality
> is a good idea.

Yeah, we can't really remove it until we have a plausible substitute for
the xpath_table functionality. This is in the TODO list ...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Josh Berkus on 28 Jan 2010 17:54

> Yeah, we can't really remove it until we have a plausible substitute for
> the xpath_table functionality. This is in the TODO list ...

What about moving it to pgfoundry?

I'm really not keen on shipping known-broken stuff in /contrib.

--Josh Berkus

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 28 Jan 2010 19:31
On Thu, Jan 28, 2010 at 5:54 PM, Josh Berkus <josh(a)agliodbs.com> wrote:
>> Yeah, we can't really remove it until we have a plausible substitute for
>> the xpath_table functionality.  This is in the TODO list ...
>
> What about moving it to pgfoundry?
>
> I'm really not keen on shipping known-broken stuff in /contrib.

Yeah, exactly. Another option - if we know that it works OK with
inputs of certain types - might be to throw an error if we get an
input of a type we know it doesn't work with. But I guess I haven't
followed this closely enough to know exactly what kinds of arguments
do/don't work.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: plperl compiler warning
Next: [HACKERS] returning array in a field together with other types