Re: [PGdocs] fix description for handling pf non-ASCII characters
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Smith <smithpb2250@gmail.com>
Cc: "Karl O. Pinc" <kop@karlpinc.com>,
"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
jian he <jian.universality@gmail.com>,
Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-09-28T01:19:31Z
Lists: pgsql-hackers
Peter Smith <smithpb2250@gmail.com> writes: > I had in mind something like a SHIFT-JIS encoding where a single > "character" may include some trail bytes that happen to be in the > ASCII printable range. AFAIK because the new logic is processing > bytes, not characters, I thought the end result could be a mix of > escaped and unescaped bytes for the single SJIS character. It will not, because ... > But now looking at PostgreSQL-supported character sets [1] I saw SJIS > is not supported anyhow. Unfortunately, I am not familiar enough with > other encodings to know if there is still a chance of similar > printable ASCII trail bytes so I am fine with whatever wording is > chosen. ... trailing bytes that could be mistaken for ASCII are precisely the property that causes us to reject an encoding as not backend-safe. So this code doesn't need to consider that hazard, and processing the string byte-by-byte is perfectly OK. I'd be inclined to keep the text as simple as possible and not focus on the distinction between bytes and characters. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
doc: Fix descriptions related to the handling of non-ASCII characters
- 950e236e5069 16.1 landed
- 3ef18a90bdea 17.0 landed
-
pg_clean_ascii(): escape bytes rather than lose them
- 45b1a67a0fcb 16.0 cited
-
Make locale option behavior more consistent
- da5d4ea5aaac 16.0 cited