Re: Decision by Monday: PQescapeString() vs. encoding violation - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Decision by Monday: PQescapeString() vs. encoding violation
Date
Msg-id ehstxpqkvdirfz7uk4gtuym5sihkh23qrwldl5lpywyxunoxvc@i4fvw3angrtg
Whole thread Raw
In response to Re: Decision by Monday: PQescapeString() vs. encoding violation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Decision by Monday: PQescapeString() vs. encoding violation
List pgsql-hackers
Hi,

On 2025-02-15 14:12:06 -0500, Tom Lane wrote:
> On closer inspection, PQescapeInternal already issues only one
> error message, since it does "return NULL" after detecting the
> first error.  So this makes PQescapeStringInternal behave more
> like that.

This looks good to me.

I looked through the diff between what test_escape -v before/after this change
prints out, looks good to me.


> From 565b42cecf645b1dbde277512fd67836ee9081d1 Mon Sep 17 00:00:00 2001
> From: Tom Lane <tgl@sss.pgh.pa.us>
> Date: Sat, 15 Feb 2025 14:10:33 -0500
> Subject: [PATCH v5] Make escaping functions retain trailing bytes of an
>  invalid character.
> 
> Instead of dropping the trailing byte(s) of an invalid or incomplete
> multibyte character, replace only the first byte with a known-invalid
> sequence, and process the rest normally.  This seems less likely to
> confuse incautious callers than the behavior adopted in 5dc1e42b4.
> 
> Author: Andres Freund <andres@anarazel.de>

I think you deserve primary authorship for the change now...


Are you planning to push / backpatch, or should I?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Decision by Monday: PQescapeString() vs. encoding violation
Next
From: Jeff Davis
Date:
Subject: Re: Decision by Monday: PQescapeString() vs. encoding violation