Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vOQVI-007678-2F for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Nov 2025 01:09:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vOQVH-002SVF-15 for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Nov 2025 01:08:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vOQVG-002SV7-2z for pgsql-hackers@lists.postgresql.org; Thu, 27 Nov 2025 01:08:59 +0000 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vOQVE-001f2r-2A for pgsql-hackers@postgresql.org; Thu, 27 Nov 2025 01:08:58 +0000 Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-3418ad69672so193481a91.3 for ; Wed, 26 Nov 2025 17:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764205736; x=1764810536; darn=postgresql.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=A8RXrfZ1vPcq1Y9zfU+cYDLM+jJTb+L+Jc1pqeoHHVs=; b=HfYiu1WiztsXncw/xVb1sQxxCi1C82wcmeRMHv4vEtPnuhKO99NqPVBc4vr8H7dGoj tfszwSEO5511NDuLPvsR6WJ5qygvQjHgtJLYaOgZJ3zE0t60bySth5cgVJ2qAMX61ZiP ke2h6gGtE/7v3wMiVcMUpQDkX1aaIRZnc7LscY1UVPPwz2W+3V9Fe1Dltzp38PMs2JDF OayBhH9Nf+FO1Uh6eepRqkPgBXzGcdKhUOohtnF+6fxCeveJPOGvFxoshu5FLX27//0I gFi+Zfjo2oPNdB77dNK2L9+H0J6q/m9xYrh/Q4+QLCqcMfVt14mpWcckjaZj+Bn09Q3q qRAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764205736; x=1764810536; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=A8RXrfZ1vPcq1Y9zfU+cYDLM+jJTb+L+Jc1pqeoHHVs=; b=YL0N4e0zri93izlA+7+sBiQX31Zn2dUuG4jHVKB1vMAxeI0Z3pUYpu7hqahrRoQjpo vMIDex5RRFXHP0SsuOejiFTCEiyXZgueFD6wsc1kCqqQ+wgNa4jW8MQQYOHuGFDPpo7Z W8buz8EChuJjjA9+BSCPfIPgwQrBvC5Wn02NAlbdrTF8jL0WO4R0EhFtN/9yOS6XfQ9X K0rISg4zZniFTV5+rcjmjx7Fgf5teXdYKG0/jgBDtAOwt7BZ3vMI1jSYyMO4MkZHwV7k 43uRAj7agk/EDiperwhXYv1MOrE5mD/FlQDfDq7S3vAhP5VQBzKFJLsvQpPwxkv7b5Cy AXKw== X-Forwarded-Encrypted: i=1; AJvYcCXYuoifaAUAVsje7VRyFwOIhxKnJkemqo1XmAhxgODMjHnPROzgfhpxU8rqWHDXIBDdGojmDh1tV+02Xi6X@postgresql.org X-Gm-Message-State: AOJu0YyaKqh+uQ9RkenpzXaYK26RagjPY5kggLcM4/uULobmzJNHUvI0 VrIjPoW7Ry51xYspR2ZX0BZoECmowOraCxUC9o+yjTEntmL+xh61vIex X-Gm-Gg: ASbGncvAGKfls6zaxHuZ5ZvA6FUtNkynAqTlyomB/WepPDZIkrdufhy4S+AvIF/j0+w kersNPIstRs3VyHnIIws/CY74rMAmO83nXsaIDQm+VC/D8f4NAYBCelnnhuuQT72pjJbbRexhlz Of6+FE/UdfEXK1fdrlocLgTOp9BQZiDvFDg0J8Qzw7uR5vsbuCIuDXJf3TAoCaJgXGkfuObpMan Cr4v8ZWhRkw7hG4/GZrt1raQ41PFgCSRfXYwAjXDHhFvqCr8GFVP3j1vtRIWl7iDo1quHJv+jaG vFAKAlnsoGx9MfobgS+r8/xRUumdmrXknQVJyXEAJXViXfjNXVvz65ok0AtDAVkzf2z3rANp+9G BMI3F7zhtlzyOt51xjQm8fOojp+mBIlZ07YgT58DKNtmPO1J38MayDTu3r2sN2c5oc2qc11EWHz 5VBsI5PxCJsOrHb9e/jYEnwopgcvR1YA== X-Google-Smtp-Source: AGHT+IHzL2LtNmjCmYgPo60NLtDq46KngO7+uEnuUlX6X+Iw5eDTWC/nZm+I/NeEuh4Z8NUD0tmEHw== X-Received: by 2002:a17:90b:4ec7:b0:341:88d5:a74e with SMTP id 98e67ed59e1d1-34733f4ac35mr19345852a91.29.1764205736472; Wed, 26 Nov 2025 17:08:56 -0800 (PST) Received: from smtpclient.apple ([45.32.121.103]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3476a59444csm3829335a91.8.2025.11.26.17.08.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Nov 2025 17:08:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: Remaining dependency on setlocale() From: Chao Li In-Reply-To: <83F6E6A9-FF29-41C9-9E15-EA5360E912D0@gmail.com> Date: Thu, 27 Nov 2025 09:08:16 +0800 Cc: Peter Eisentraut , Thomas Munro , Tom Lane , pgsql-hackers@postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: <6DDB0693-29E0-41B6-AE63-F0723F7DA8CD@gmail.com> References: <4c5da86af36a0d5e430eee3f60ce5e06f1b5cd34.camel@j-davis.com> <9875f7f9-50f1-4b5d-86fc-ee8b03e8c162@eisentraut.org> <6956823dd669abc64183fc91e64dc2e56e31f3ea.camel@j-davis.com> <8186b28a1a39e61a0d833a4c25a8909ebbbabd48.camel@j-davis.com> <450ceb6260cad30d7afdf155d991a9caafee7c0d.camel@j-davis.com> <78edc741a168c54d57cc898a5877b6443527a2c8.camel@j-davis.com> <83F6E6A9-FF29-41C9-9E15-EA5360E912D0@gmail.com> To: Jeff Davis X-Mailer: Apple Mail (2.3826.700.81) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On Nov 26, 2025, at 09:50, Chao Li wrote: >=20 > I will review the rest 3 commits tomorrow. 10 - 0009 ``` { if (isalpha((unsigned char) c)) { - c =3D toupper((unsigned char) c); + c =3D pg_ascii_toupper((unsigned char) c); ``` Just curious. As isaplha() and toupper() come from the same header file = ctype.h, if we replace toupper with pg_ascii_toupper, does isapha also = need to be handled? 11 - 0010 ``` - for (i =3D 0; i < len; i++) - { - unsigned char ch =3D (unsigned char) ident[i]; + dstsize =3D len + 1; + result =3D palloc(dstsize); =20 - if (ch >=3D 'A' && ch <=3D 'Z') - ch +=3D 'a' - 'A'; - else if (enc_is_single_byte && IS_HIGHBIT_SET(ch) && = isupper(ch)) - ch =3D tolower(ch); - result[i] =3D (char) ch; - } - result[i] =3D '\0'; + needed =3D pg_strfold_ident(result, dstsize, ident, len); + Assert(needed + 1 =3D=3D dstsize); + Assert(needed =3D=3D len); ``` I think assert both dstsize and len are redundant, because = dstsize=3Dlen+1, and no place to change their values. 12 - 0010 ``` +/* + * Fold an identifier using the database default locale. + * + * For historical reasons, does not use ordinary locale behavior. = Should only + * be used for identifier folding. XXX: can we make this equivalent to + * pg_strfold(..., default_locale)? + */ +size_t +pg_strfold_ident(char *dest, size_t destsize, const char *src, ssize_t = srclen) +{ + if (default_locale =3D=3D NULL || default_locale->ctype =3D=3D = NULL) + { + int i; + + for (i =3D 0; i < srclen && i < destsize; i++) + { + unsigned char ch =3D (unsigned char) src[i]; + + if (ch >=3D 'A' && ch <=3D 'Z') + ch +=3D 'a' - 'A'; + dest[i] =3D (char) ch; + } + + if (i < destsize) + dest[i] =3D '\0'; + + return srclen; + } + return default_locale->ctype->strfold_ident(dest, destsize, src, = srclen, + = default_locale); +} ``` Given default_local can be NULL only at some specific moment, can we do = something like Local =3D default_local; If (local =3D=3D NULL || local->ctype =3D=3D NULL) Local =3D libc or other fallback; Return default_locale->ctype->strfold_ident(dest, destsize, src, srclen, = local); This way avoids the duplicate code. 13 - 0011 ``` +{ name =3D> 'lc_collate', type =3D> 'string', context =3D> 'PGC_SUSET', = group =3D> 'CLIENT_CONN_LOCALE', + short_desc =3D> 'Sets the locale for text ordering in extensions.', ``` I just feel the GUC name is very misleading. Without carefully reading = the doc, users may very easy to consider lc_collate the system=E2=80=99s = locale. If it only affects extensions, then let=E2=80=99s name it = accordingly, for example, =E2=80=9Cextension_lc_collate=E2=80=9D, or = =E2=80=9Clegacy_lc_collate=E2=80=9D. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/