mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-03-25 20:10:41 +08:00
ae6d06f096
This commit comes as a continuation of the discussion that has led to d522b05, as \v was handled inconsistently when parsing array values or anything going through the parsers, and changing a parser behavior in stable branches is a scary thing to do. The parsing of array values now uses the more central scanner_isspace() and array_isspace() is removed. As pointing out by Peter Eisentraut, fix a confusing reference to horizontal space in the parsers with the term "horiz_space". \f was included in this set since 3cfdd8f from 2000, but it is not horizontal. "horiz_space" is renamed to "non_newline_space", to refer to all whitespace characters except newlines. The changes impact the parsers for the backend, psql, seg, cube, ecpg and replication commands. Note that JSON should not escape \v, as per RFC 7159, so these are not touched. Reviewed-by: Peter Eisentraut, Tom Lane Discussion: https://postgr.es/m/ZJKcjNwWHHvw9ksQ@paquier.xyz
27 lines
855 B
SQL
27 lines
855 B
SQL
/*
|
|
* 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;
|
|
SELECT 'keyą=>valueą'::hstore;
|
|
SELECT 'ą=>ą'::hstore;
|
|
SELECT 'keyąfoo=>valueą'::hstore;
|
|
|
|
-- More patterns that may depend on isspace() and locales, all discarded.
|
|
SELECT E'key\u000A=>value\u000A'::hstore; -- \n
|
|
SELECT E'key\u0009=>value\u0009'::hstore; -- \t
|
|
SELECT E'key\u000D=>value\u000D'::hstore; -- \r
|
|
SELECT E'key\u000B=>value\u000B'::hstore; -- \v
|
|
SELECT E'key\u000C=>value\u000C'::hstore; -- \f
|