From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us |
Subject: | Re: Decision by Monday: PQescapeString() vs. encoding violation |
Date: | 2025-02-15 20:43:22 |
Message-ID: | 5paqlw7soc66ud5ny3uq27qeeufo2pcm276rvv75hjhvns2sme@bvbqnxivxb2m |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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."
>
> The patch implements the latter. Escaping:
> <7A F0 80 80 41 7A>
> results in:
> <7A C0 20 C0 20 C0 20 41 7A>
>
> The Unicode standard suggests[2] that the former approach may provide
> more consistency in how it's done, but that doesn't seem important or
> relevant for our purposes. I'd favor whichever approach results in
> simpler code.
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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-02-15 20:52:01 | Re: Decision by Monday: PQescapeString() vs. encoding violation |
Previous Message | Jeff Davis | 2025-02-15 20:35:45 | Re: Decision by Monday: PQescapeString() vs. encoding violation |