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>
Cc: Michael Paquier <michael@paquier.xyz>, 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>, Jeff Davis <pgsql@j-davis.com>
Date: 2023-04-22T19:14:49Z
Lists: pgsql-hackers 
On 4/19/23 9:34 PM, Thomas Munro wrote:
> On Wed, Apr 19, 2023 at 2:31 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>> 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 all.  I went ahead and removed check_strxfrm_bug().

Thanks! For housekeeping, I put this into "Open Items" and marked it as 
resolved.

> I could write a patch to remove the libc strxfrm support, but since
> Jeff recently wrote new code in 16 to abstract that stuff, he might
> prefer to look at it?

I believe we'd be qualifying this as an open item too? If so, let's add it.

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.