On Tue, Jun 06, 2023 at 10:16:09AM -0400, Evan Jones wrote:
> I did a quick look at the places found with "git grep isspace" yesterday. I
> agree with the comment from commit 9ae2661: "I've left alone isspace()
> calls in places that aren't really expecting any non-ASCII input
> characters, such as float8in()." There are a number of other calls where I
> think it would likely be safe, and possibly even a good idea, to replace
> isspace() with scanner_isspace(). However, I couldn't find any where I
> could cause a bug like the one I hit in hstore parsing.
Yes, I agree with this feeling. Like 9ae2661, I can't get really
excited about plastering more of that, especially if it were for
timezone value input or dictionary options. One area with a new
isspace() since 2017 is multirangetypes.c, but it is just a copy of
rangetypes.c.
> Original mailing list post for commit 9ae2661 in case it is helpful for
> others: https://www.postgresql.org/message-id/10129.1495302480@sss.pgh.pa.us
I have reproduced the original problem reported on macOS 13.4, which
is close to the top of what's available.
Passing to pg_regress some options to use something else than UTF-8
leads to a failure in the tests, so we need a split like
fussyztrmatch to test that:
REGRESS_OPTS='--encoding=SQL_ASCII --no-locale' make check
An other error pattern without a split could be found on Windows, as
of:
select E'key\u0105=>value'::hstore;
- hstore
------------------
- "keyÄ…"=>"value"
-(1 row)
-
+ERROR: character with byte sequence 0xc4 0x85 in encoding "UTF8" has
no equivalent in encoding "WIN1252"
+LINE 1: select E'key\u0105=>value'::hstore;
We don't do that for unaccent, actually, leading to similar failures..
I'll launch a separate thread about that shortly.
With that fixed, the fix has been applied and backpatched. Thanks for
the report, Evan!
--
Michael