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
>
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 |