Re: Decision by Monday: PQescapeString() vs. encoding violation
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Jeff Davis <pgsql@j-davis.com>, Noah Misch <noah@leadboat.com>,
pgsql-hackers@postgresql.org
Date: 2025-02-15T20:52:01Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2025-02-15 12:35:45 -0800, Jeff Davis wrote: >> I am not suggesting a change, but there's a minor point about the >> behavior of the replacement that I'd like to highlight: >> Unicode discusses a choice[1]: "An ill-formed subsequence consisting of >> more than one code unit could be treated as a single error or as >> multiple errors." > It seems completely infeasible to me to to implement the "single error" > approach in a minor version. It'd afaict require non-trivial new > infrastructure. We can't just consume up to the next byte without a high bit, > because some encodings have subsequent bytes that are not guaranteed to have a > high bit set. Yeah. Also I think that probably depends on being able to tell the difference between a first byte and a not-first byte of a multibyte character, something that works in UTF-8 but not necessarily elsewhere. As I commented in the security thread, Unicode's recommendations seem pretty UTF-8-centric; I'm hesitant to adopt them wholesale in code that has to deal with other encodings. The v5 patch seems Good Enough(TM) to me. We can refine it later perhaps; I don't think something like the above would affect anything that external code should care about. regards, tom lane
Commits
-
Make escaping functions retain trailing bytes of an invalid character.
- e782a63ccb76 15.12 landed
- d6d29b2133f1 13.20 landed
- c08309584ac5 14.17 landed
- 9f45e6a91d84 18.0 landed
- 991a60a9f23b 16.8 landed
- 3abe6e04cc69 17.4 landed
-
Fix handling of invalidly encoded data in escaping functions
- 5dc1e42b4fa6 18.0 cited