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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org, andres(at)anarazel(dot)de, pgsql(at)j-davis(dot)com
Subject: Re: Decision by Monday: PQescapeString() vs. encoding violation
Date: 2025-02-15 18:08:03
Message-ID: 77190.1739642883@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I studied the v3 patch a little and realized that it only fixes the
behavior for the case of a complete-but-invalid multibyte character.
If we have an incomplete character at the end of the string, the
whole thing still gets dropped. Surely that's not what we want if
we are going to adopt this behavior.

Here's a v4 that fixes that. As a bonus, we can get rid of
duplicative coding since the "incomplete" and "invalid" cases
are now treated identically.

One minor point is that the error messages from PQescapeStringInternal
no longer distinguish "incomplete" from "invalid". I don't find that
to be a terribly useful distinction, so that's fine with me. But if
someone feels that's important to preserve, we could make it do
something like

if (conn)
{
if (remaining < charlen)
libpq_append_conn_error(conn, "incomplete multibyte character");
else
libpq_append_conn_error(conn, "invalid multibyte character");
}

regards, tom lane

Attachment Content-Type Size
v4-0001-Make-escaping-functions-retain-trailing-bytes-of-.patch text/x-diff 9.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-02-15 18:23:51 Re: Decision by Monday: PQescapeString() vs. encoding violation
Previous Message Christoph Berg 2025-02-15 17:22:49 Re: pg17.3 PQescapeIdentifier() ignores len