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 |
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 |