Horton

Re: check_strxfrm_bug()

Jonathan S. Katz <jkatz@postgresql.org>

View thread View on postgr.es
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Thomas Munro <thomas.munro@gmail.com>, Michael Paquier <michael@paquier.xyz>
Cc: Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>, Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>
Date: 2023-04-19T02:31:15Z
Lists: pgsql-hackers 
On 4/18/23 9:19 PM, Thomas Munro wrote:
> On Tue, Apr 18, 2023 at 11:52 AM Michael Paquier <michael@paquier.xyz> wrote:
>> On Mon, Apr 17, 2023 at 03:40:14PM -0700, Peter Geoghegan wrote:
>>> +1 for getting rid of TRUST_STRXFRM.
> 
> +1
> 
> The situation is not improving fast, and requires hard work to follow
> on each OS.  Clearly, mainstreaming ICU is the way to go.  libc
> support will always have niche uses, to be compatible with other
> software on the box, but trusting strxfrm doesn't seem to be on the
> cards any time soon.

[RMT hat, personal opinion on RMT]

To be clear, is the proposal to remove both "check_strxfrm_bug" and 
"TRUST_STRXFRM"?

Given a bunch of folks who have expertise in this area of code all agree 
with removing the above as part of the collation cleanups targeted for 
v16, I'm inclined to agree. I don't really see the need for an explicit 
RMT action, but based on the consensus this seems OK to add as an open item.

Thanks,

Jonathan

Commits

  1. Don't expose Windows' mbstowcs_l() and wcstombs_l().

  2. All supported systems have locale_t.

  3. Remove obsolete defense against strxfrm() bugs.