Skip site navigation (1) Skip section navigation (2)

Re: remove contrib/xml2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: remove contrib/xml2
Date: 2010-02-28 21:46:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I believe I have fixed all the reported crashes in contrib/xml2.
However there is still this issue pointed out by Robert:

> CREATE TABLE xpath_test (id integer NOT NULL, t xml);
> INSERT INTO xpath_test VALUES (1, '<rowlist><row a="1"/><row a="2" b="oops"/></rowlist>');
> SELECT * FROM xpath_table('id', 't', 'xpath_test',
> '/rowlist/row/@a|/rowlist/row/@b', 'true') as t(id int4, a text, b text);

> which yields an answer that is, at least, extremely surprising, if not
> flat-out wrong:

>  id | a |  b
> ----+---+------
>   1 | 1 | oops
>   1 | 2 |
> (2 rows)

the point being that it seems like "oops" should be associated with "2"
not "1".  The reason for that behavior is that xpath_table runs through
the XPATH_NODESET results generated by the various XPaths and dumps the
k'th one of each into the k'th output row generated for the current
input row.  If there is any way to synchronize which node in each array
goes with each node in each other array, it's not apparent to me, but
I don't know libxml's API at all.  Perhaps there is some other call we
should be using to evaluate all the XPaths in parallel?

(The code is also unbelievably inefficient, recompiling each XPath
expression once per output row (!); but it doesn't seem worth fixing
that right away given that we might have to throw away the logic
entirely in order to fix this bug.)

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-02-28 21:58:51
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Previous:From: Joachim WielandDate: 2010-02-28 21:42:00
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group