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: "Karl O. Pinc" <kop@karlpinc.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
"'jian he'" <jian.universality@gmail.com>,
Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-09-26T18:01:23Z
Lists: pgsql-hackers
"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. A smell test that works for native speakers (not sure how helpful it is for others) is: if the sentence would read well with commas or parens added before and after the clause, then it's probably non-restrictive and should use "which". If it looks wrong that way then it's a restrictive clause and should use "that". 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