Re: SQL/JSON path: collation for comparisons, minor typos in docs
Alexander Korotkov <a.korotkov@postgrespro.ru>
From: Alexander Korotkov <a.korotkov@postgrespro.ru>
To: Markus Winand <markus.winand@winand.at>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-08-07T21:55:55Z
Lists: pgsql-hackers
Attachments
- 0001-Use-Unicode-codepoint-collation-in-jsonpath-2.patch (application/octet-stream) patch 0001
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’t follow the standard. > > > > The functionality in question are the comparison operators except ==. They use the database default collation rather then the standard-mandated "Unicode codepoint collation” (SQL-2:2016 9.39 General Rule 12 c iii 2 D, last sentence in 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. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Commits
-
Adjust string comparison in jsonpath
- 3218ff5c6aea 12.0 landed
- d54ceb9e1761 13.0 landed
-
Fix some typos in jsonpath documentation
- 53d467246589 12.0 landed
- 1f33f211bc53 13.0 landed