Spyridon Dimitrios Agathos <spyridon.dimitrios.agathos@gmail.com> writes:
> this is to verify that the .patch proposed here:
> https://www.postgresql.org/message-id/flat/2318797.1638558730%40sss.pgh.pa.us
> fixes the issue.
> Looking forward to the next steps.
That's been committed into HEAD and v15, without pushback so far.
So the complained-of case is no longer reachable in those branches.
I think we should reject Aleksander's patch, on the grounds that
it's now unnecessary --- or if you want to argue that it's still
necessary, then it's woefully inadequate, because there are surely
a bunch of other text-processing functions that will also misbehave
on wrongly-encoded data. But our general policy for years has been
that we check incoming text for encoding validity and then presume
that it is valid in manipulation operations.
What remains to be debated is whether to push ec62ce55a into the
stable branches. While we've not had pushback about the change
in 15beta3, that hasn't been out very long, so I don't know how
much faith to put in the lack of complaints. Should we wait
longer before deciding?
I'm leaning to the idea that we should not back-patch, because
this issue has been there for years with few complaints; it's
not clear that closing the hole is worth creating a compatibility
hazard in minor releases. On the other hand, you could argue
that we should back-patch so that back-branch charin() will
understand the strings that can now be emitted by v15 charout().
Failing to do so will result in a different sort of compatibility
problem.
regards, tom lane