mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-07-15 17:01:10 +02:00
3a5222a432
isspace() can be locale-sensitive depending on the platform, causing
hstore to consider as whitespaces characters it should not see as such.
For example, U+0105, being decoded as 0xC4 0x85 in UTF-8, would be
discarded from the input given.
This problem is similar to 9ae2661, though it was missed that hstore
can also manipulate non-ASCII inputs, so replace the existing isspace()
calls with scanner_isspace().
This problem exists for a long time, so backpatch all the way down.
Author: Evan Jones
Discussion: https://postgr.es/m/CA+HWA9awUW0+RV_gO9r1ABZwGoZxPztcJxPy8vMFSTbTfi4jig@mail.gmail.com
Backpatch-through: 11
37 lines
790 B
Plaintext
37 lines
790 B
Plaintext
/*
|
|
* This test must be run in a database with UTF-8 encoding,
|
|
* because other encodings don't support all the characters used.
|
|
*/
|
|
SELECT getdatabaseencoding() <> 'UTF8'
|
|
AS skip_test \gset
|
|
\if :skip_test
|
|
\quit
|
|
\endif
|
|
SET client_encoding = utf8;
|
|
-- UTF-8 locale bug on macOS: isspace(0x85) returns true. \u0105 encodes
|
|
-- as 0xc4 0x85 in UTF-8; the 0x85 was interpreted here as a whitespace.
|
|
SELECT E'key\u0105=>value\u0105'::hstore;
|
|
hstore
|
|
------------------
|
|
"keyą"=>"valueą"
|
|
(1 row)
|
|
|
|
SELECT 'keyą=>valueą'::hstore;
|
|
hstore
|
|
------------------
|
|
"keyą"=>"valueą"
|
|
(1 row)
|
|
|
|
SELECT 'ą=>ą'::hstore;
|
|
hstore
|
|
----------
|
|
"ą"=>"ą"
|
|
(1 row)
|
|
|
|
SELECT 'keyąfoo=>valueą'::hstore;
|
|
hstore
|
|
---------------------
|
|
"keyąfoo"=>"valueą"
|
|
(1 row)
|
|
|