Re: [PATCH] hstore: Fix parsing on Mac OS X: isspace() is locale specific
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Evan Jones <evan.jones@datadoghq.com>, pgsql-hackers@postgresql.org
Date: 2023-10-10T03:17:57Z
Lists: pgsql-hackers
FTR I ran into a benign case of the phenomenon in this thread when dealing with row types. In rowtypes.c, we double-quote stuff containing spaces, but we detect them by passing individual bytes of UTF-8 sequences to isspace(). Like macOS, Windows thinks that 0xa0 is a space when you do that, so for example the Korean character '점' (code point C810, UTF-8 sequence EC A0 90) gets quotes on Windows but not on Linux. That confused a migration/diff tool while comparing Windows and Linux database servers using that representation. Not a big deal, I guess no one ever promised that the format was stable across platforms, and I don't immediately see a way for anything more serious to go wrong (though I may lack imagination). It does seem a bit weird to be using locale-aware tokenising for a machine-readable format, and then making sure its behaviour is undefined by feeding it chopped up bytes.
Commits
-
CREATE DATABASE: make LOCALE apply to all collation providers.
- a14e75eb0b6a 16.0 cited
-
hstore: Tighten key/value parsing check for whitespaces
- bbfc26d861fa 11.21 landed
- edf1de65e529 12.16 landed
- 78bf0a256d12 13.12 landed
- e0e6829459b0 14.9 landed
- 3a5222a432be 15.4 landed
- d522b05c8c1c 16.0 landed
-
Tighten checks for whitespace in functions that parse identifiers etc.
- 9ae2661fe1fe 10.0 cited