Re: BUG #16091: xpath fails to compute "name()", regression

From: Cherio <cherio(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16091: xpath fails to compute "name()", regression
Date: 2019-10-30 20:08:46
Message-ID: CAKHqFk+3EWzphe7DTPY_JYb+fHmentAfLCX-rrmAMAj_AZu+sA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thanks Tom,

This is what we essentially did to make the old code work.
I guess you are saying this is not considered a regression.
Than this is not a bug.

On Wed, Oct 30, 2019 at 2:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > After upgrading postgresql from 9 to 12 the following statement no longer
> > produces the same result: SELECT xpath('name()', '<abc>xyz</abc>'::XML)
>
> > PostgreSQL 9 returns '{abc}'
> > PostgreSQL 12 returns '{""}'
>
> > This behavior changed in version 11 and perpetuated into 12.
>
> This looks to me to be an intentional change in xpath's behavior.
> The v11 release notes call out the incompatibility:
>
> 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.
>
> Perhaps 'name(/*)' would do what you want now.
>
> regards, tom lane
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2019-10-30 20:30:14 Re: BUG #16082: TOAST's pglz_decompress access to uninitialized data, if the database is corrupted.
Previous Message Tomas Vondra 2019-10-30 18:16:12 Re: memory problems and crash of db when deleting data from table with thousands of partitions