Re: [PGdocs] fix description for handling pf non-ASCII characters
Karl O. Pinc <kop@karlpinc.com>
From: "Karl O. Pinc" <kop@karlpinc.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, 'jian he' <jian.universality@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-09-26T21:50:20Z
Lists: pgsql-hackers
Sep 26, 2023 1:10:55 PM Tom Lane <tgl@sss.pgh.pa.us>: > "Karl O. Pinc" <kop@karlpinc.com> writes: >> For the last hunk you'd change around "anything". Write: >> "... it will be truncated to less than NAMEDATALEN characters and >> the bytes of the string which are not printable ASCII characters ...". > >> Notice that I have also changed "that" to "which" just above. >> I _think_ this is better English. > > No, I'm pretty sure you're mistaken. It's been a long time since > high school English, but the way I think this works is that "that" > introduces a restrictive clause, which narrows the scope of what > you are saying. That is, you say "that" when you want to talk > about only the bytes of the string that aren't ASCII. But "which" > introduces a non-restrictive clause that adds information or > commentary. If you say "bytes of the string which are not ASCII", > you are effectively making a side assertion that no byte of the > string is ASCII. Which is not the meaning you want here. Makes sense to me. "That" it is. Thanks for the help. I never would have figured that out.
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