BUG #4294: XML support: name() xpath function not working

On Thu, 2008-07-10 at 08:52 +0000, Enrico Sirola wrote:

create table test (test xml);
insert into test values ('<a
xmlns="http://myns.com/ns&quot;&gt;&lt;b&gt;text1&lt;/b&gt;&lt;c&gt;text2&lt;/c&gt;&lt;/a&gt;&#39;);
-- good
select xpath('/my:a/*[last()]', test, ARRAY[ARRAY['my',
'http://myns.com/ns&#39;]]) from test;
-- bad
select xpath('name(/my:a/*[last()])', test, ARRAY[ARRAY['my',
'http://myns.com/ns&#39;]]) from test;

What error messages are you getting?

Why do you think this should work? Best post a test case using another
tool, or a URL to an example.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

"Enrico Sirola" <enrico.sirola@gmail.com> writes:

-- bad
select xpath('name(/my:a/*[last()])', test, ARRAY[ARRAY['my',
'http://myns.com/ns&#39;]]) from test;

You could barely swat a fly with what I know about XPath ... but I'm
thinking that the culprit here is the crock at lines 3254-3288 of
xml.c, which explains itself thus:

/*
* To handle both documents and fragments, regardless of the fact whether
* the XML datum has a single root (XML well-formedness), we wrap the XML
* datum in a dummy element (<x>...</x>) and extend the XPath expression
* accordingly. To do it, throw away the XML prolog, if any.
*/

This code prefixes the given path expression with "/x", which of course
is going to break any expression that starts with a function name. It
would have to stick the /x inside the function argument to have any
chance of working. In general, I think this has zero chance of working
without implementing a pretty complete XPath parser. We need to find
another way.

regards, tom lane

Is there any TODO here?

---------------------------------------------------------------------------

Tom Lane wrote:

"Enrico Sirola" <enrico.sirola@gmail.com> writes:

-- bad
select xpath('name(/my:a/*[last()])', test, ARRAY[ARRAY['my',
'http://myns.com/ns&#39;]]) from test;

You could barely swat a fly with what I know about XPath ... but I'm
thinking that the culprit here is the crock at lines 3254-3288 of
xml.c, which explains itself thus:

/*
* To handle both documents and fragments, regardless of the fact whether
* the XML datum has a single root (XML well-formedness), we wrap the XML
* datum in a dummy element (<x>...</x>) and extend the XPath expression
* accordingly. To do it, throw away the XML prolog, if any.
*/

This code prefixes the given path expression with "/x", which of course
is going to break any expression that starts with a function name. It
would have to stick the /x inside the function argument to have any
chance of working. In general, I think this has zero chance of working
without implementing a pretty complete XPath parser. We need to find
another way.

regards, tom lane

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

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Is there any TODO here?

It's clearly broken, if that's what you mean. I don't know enough XPath
to speculate about an appropriate fix.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Is there any TODO here?

It's clearly broken, if that's what you mean. I don't know enough XPath
to speculate about an appropriate fix.

The XML wiki already had bug reports about <x> so I added this report to
that list.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +