Re: [HACKERS] possible encoding issues with libxml2 functions - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] possible encoding issues with libxml2 functions
Date
Msg-id CAFj8pRDLD0+ntoS-sozcOeSvJUX8mzPdMCbnMoZvLG-ekwAnEg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] possible encoding issues with libxml2 functions  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] possible encoding issues with libxml2 functions  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


xpath-bugfix.patch affected only xml values containing an xml declaration with
"encoding" attribute.  In UTF8 databases, this latest proposal
(xpath-parsing-error-fix.patch) is equivalent to xpath-bugfix.patch.  In
non-UTF8 databases, xpath-parsing-error-fix.patch affects all xml values
containing non-ASCII data.  In a LATIN1 database, the following works today
but breaks under your latest proposal:

  SELECT xpath('text()', ('<x>' || convert_from('\xc2b0', 'LATIN1') || '</x>')::xml);

It's acceptable to break that, since the documentation explicitly disclaims
support for it.  xpath-bugfix.patch breaks different use cases, which are
likewise acceptable to break.  See my 2017-08-08 review for details.

The fact so this code is working shows so a universe is pretty dangerous place :) 

 

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] expanding inheritance in partition bound order
Next
From: Haribabu Kommi
Date:
Subject: Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall