pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedpossible bug in xpath function
3+ messages / 2 participants
[nested] [flat]
* possible bug in xpath function
@ 2022-03-10 14:07 Andrey Kapliev <a.kapliev@gmail.com>
2022-03-11 15:53 ` Re: possible bug in xpath function Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 3+ messages in thread
From: Andrey Kapliev @ 2022-03-10 14:07 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"; xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=RU link=blue vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-US>Hi, </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>Issue is described here </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>https://stackoverflow.com/questions/71408524/get-list-of-nodenames-in-postgresql-xpath</span>&... class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>version:</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>"PostgreSQL 14.1, compiled by Visual C++ build 1914, 64-bit"</span><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span lang=EN-US>Request</span><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span lang=EN-US>SELECT xpath('name()', '<name1><name2>test1</name2><name3>test2</name3></name1>')::varchar;</span><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span lang=EN-US>returns an empty list, but is expected to return name of the element (as it does in 9.6 version).</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>Same result occurs while calling</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>SELECT xpath('name()', unnest(xpath('//*', '<foo><bar>test</bar><zar>test1</zar></foo>')));</span><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span lang=EN-US>It returns empty list.</span><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span lang=EN-US>Meanwhile request</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><p class=MsoNormal>SELECT * FROM <o:p></o:p></p><p class=MsoNormal> XMLTABLE('//*' PASSING '<foo><bar>test</bar><zar>test1</zar></foo>'<o:p></o:p></p><p class=MsoNormal> COLUMNS<o:p></o:p></p><p class=MsoNormal> name varchar PATH 'name()');<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span lang=EN-US>rightfully returns list of element names.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>It looks like XPATH name() function called from xpath() PostgreSQL function behave differently than when called from XMLTABLE() PATH</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>This behavior is different from that of 9.6 version where xpath correctly returns names of the nodes.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>Same issue refers to local-name(), namespace-uri() XPath functions.</span><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span lang=EN-US>Best regards,</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>Andrey Kapliev</span><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: possible bug in xpath function
2022-03-10 14:07 possible bug in xpath function Andrey Kapliev <a.kapliev@gmail.com>
@ 2022-03-11 15:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-03-11 16:09 ` Re: possible bug in xpath function Andrey Kapliev <a.kapliev@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2022-03-11 15:53 UTC (permalink / raw)
To: Andrey Kapliev <a.kapliev@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Andrey Kapliev <a.kapliev@gmail.com> writes:
> It looks like XPATH name() function called from xpath() PostgreSQL
> function behave differently than when called from XMLTABLE()
> PATH.
Your examples are by no means equivalent: in particular the XMLTABLE
example is using an absolute path //* while the xpath example
is implicitly using a relative path.
> This
> behavior is different from that of 9.6 version where xpath correctly
> returns names of the nodes.
I think this was an intentional change in v11. The 11.0 release
notes mention
* Correctly handle relative path expressions in xmltable(), xpath(), and
other XML-handling functions (Markus Winand)
Per the SQL standard, relative paths start from the document node of
the XML input document, not the root node as these functions
previously did.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: possible bug in xpath function
2022-03-10 14:07 possible bug in xpath function Andrey Kapliev <a.kapliev@gmail.com>
2022-03-11 15:53 ` Re: possible bug in xpath function Tom Lane <tgl@sss.pgh.pa.us>
@ 2022-03-11 16:09 ` Andrey Kapliev <a.kapliev@gmail.com>
0 siblings, 0 replies; 3+ messages in thread
From: Andrey Kapliev @ 2022-03-11 16:09 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Hi, I did not mensioned it but there is no difference in behavoir with relative and absolute paths. It throws error - invalid XPath statement in any case when I'm trying to use any of name(), local-name(), namespace-uri() functionse irrelative of path stated
Best regards,
Andrey
Get Outlook for Android<https://aka.ms/AAb9ysg;
________________________________
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Friday, March 11, 2022 6:53:15 PM
To: Andrey Kapliev <a.kapliev@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: possible bug in xpath function
Andrey Kapliev <a.kapliev@gmail.com> writes:
> It looks like XPATH name() function called from xpath() PostgreSQL
> function behave differently than when called from XMLTABLE()
> PATH.
Your examples are by no means equivalent: in particular the XMLTABLE
example is using an absolute path //* while the xpath example
is implicitly using a relative path.
> This
> behavior is different from that of 9.6 version where xpath correctly
> returns names of the nodes.
I think this was an intentional change in v11. The 11.0 release
notes mention
* Correctly handle relative path expressions in xmltable(), xpath(), and
other XML-handling functions (Markus Winand)
Per the SQL standard, relative paths start from the document node of
the XML input document, not the root node as these functions
previously did.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2022-03-11 16:09 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-03-10 14:07 possible bug in xpath function Andrey Kapliev <a.kapliev@gmail.com>
2022-03-11 15:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-03-11 16:09 ` Andrey Kapliev <a.kapliev@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox