Re: changing xpath() and xpath_exists() - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: changing xpath() and xpath_exists()
Date
Msg-id f7fe6073-ef93-60de-ef58-c3013aeca2bc@2ndQuadrant.com
Whole thread Raw
In response to changing xpath() and xpath_exists()  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers

On 06/20/2018 07:35 PM, Alvaro Herrera wrote:
> Hello
>
> Per discussion at
> https://postgr.es/m/0684A598-002C-42A2-AE12-F024A324EAE4@winand.at
> I intend to change xpath() and xpath_exists() in a subtly backwards-
> incompatible way, so that they match the behavior of SQL-standard-
> specified XMLTABLE.  It seems sane to keep them in sync.  Anybody wants
> to object so that we keep the historical functions alone and only change
> XMLTABLE?
>
> Previously, this query would return empty:
> SELECT xpath('root', '<root/>');
>
>   xpath
> ───────
>   {}
> (1 fila)
>
> After this patch, it will return the root node:
>
>     xpath
> ───────────
>   {<root/>}
> (1 fila)
>
>
> Note that if an absolute path is used, the behavior is unchanged:
>
> alvherre=# SELECT xpath('/root', '<root/>');
>     xpath
> ───────────
>   {<root/>}
> (1 fila)
>
> Please speak up if you think the former behavior should be kept.
>


So the existing behaviour is looking for a child of the root node called 
'root'? I agree that seems broken.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: partition -> partitioned
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: PATCH: backtraces for error messages