Re: changing xpath() and xpath_exists()

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: changing xpath() and xpath_exists()
Date: 2018-06-21 00:19:02
Message-ID: f7fe6073-ef93-60de-ef58-c3013aeca2bc@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tsunakawa, Takayuki 2018-06-21 00:22:50 RE: PATCH: backtraces for error messages
Previous Message Amit Langote 2018-06-21 00:17:28 Re: partition -> partitioned