On Thu, Aug 8, 2019 at 3:05 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> On Thu, Aug 8, 2019 at 12:55 AM Alexander Korotkov
> <a.korotkov@postgrespro.ru> wrote:
> > On Wed, Aug 7, 2019 at 4:11 PM Alexander Korotkov
> > <a.korotkov@postgrespro.ru> wrote:
> > > On Wed, Aug 7, 2019 at 2:25 PM Markus Winand <markus.winand@winand.at> wrote:
> > > > I was playing around with JSON path quite a bit and might have found one case where the current implementation
doesn’tfollow the standard.
> > > >
> > > > The functionality in question are the comparison operators except ==. They use the database default collation
ratherthen the standard-mandated "Unicode codepoint collation” (SQL-2:2016 9.39 General Rule 12 c iii 2 D, last
sentencein first paragraph).
> > >
> > > Thank you for pointing! Nikita is about to write a patch fixing that.
> >
> > Please, see the attached patch.
> >
> > Our idea is to not sacrifice "==" operator performance for standard
> > conformance. So, "==" remains per-byte comparison. For consistency
> > in other operators we compare code points first, then do per-byte
> > comparison. In some edge cases, when same Unicode codepoints have
> > different binary representations in database encoding, this behavior
> > diverges standard. In future we can implement strict standard
> > conformance by normalization of input JSON strings.
>
> Previous version of patch has buggy implementation of
> compareStrings(). Revised version is attached.
Nikita pointed me that for UTF-8 strings per-byte comparison result
matches codepoints comparison result. That allows simplify patch a
lot.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company