From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: possible encoding issues with libxml2 functions |
Date: | 2017-10-15 16:25:16 |
Message-ID: | CAFj8pRAd6v3VnTQCaRKbfPasWHCVTQS5qq+fTqA6wCPAzje27g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2017-08-21 6:25 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>
>
>> 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 :)
>
>
ping?
will we continue in this topic?
>
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2017-10-15 17:08:05 | Re: SIGSEGV in BRIN autosummarize |
Previous Message | Vik Fearing | 2017-10-15 13:28:52 | Re: [PATCH] pageinspect function to decode infomasks |