Re: possible bug in xpath function - Mailing list pgsql-bugs

From Andrey Kapliev
Subject Re: possible bug in xpath function
Date
Msg-id AM8PR04MB7380CC16C61DA2E9BC742FEBA70C9@AM8PR04MB7380.eurprd04.prod.outlook.com
Whole thread Raw
In response to Re: possible bug in xpath function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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


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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: possible bug in xpath function
Next
From: Tom Lane
Date:
Subject: Re: BUG #17409: Unable to alter data type of clustered column which is referenced by foreign key