Re: Decision by Monday: PQescapeString() vs. encoding violation

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

In response to

Responses

Browse pgsql-hackers by date

  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