Handle \v as a whitespace character in parsers
authorMichael Paquier <michael@paquier.xyz>
Wed, 5 Jul 2023 23:16:24 +0000 (08:16 +0900)
committerMichael Paquier <michael@paquier.xyz>
Wed, 5 Jul 2023 23:16:24 +0000 (08:16 +0900)
commitae6d06f09684d8f8a7084514c9b35a274babca61
treed1d4572bb1224f16f36b80a8c64ede605a698530
parent4f4d73466d71976b58f29121bab9d9fef6f3436e
Handle \v as a whitespace character in parsers

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
13 files changed:
contrib/cube/cubescan.l
contrib/hstore/expected/hstore_utf8.out
contrib/hstore/sql/hstore_utf8.sql
contrib/seg/segscan.l
src/backend/parser/parse_type.c
src/backend/parser/scan.l
src/backend/parser/scansup.c
src/backend/replication/repl_scanner.l
src/backend/utils/adt/arrayfuncs.c
src/bin/psql/psqlscanslash.l
src/fe_utils/psqlscan.l
src/fe_utils/string_utils.c
src/interfaces/ecpg/preproc/pgc.l