Horton

Re: On non-Windows, hard depend on uselocale(3)

Heikki Linnakangas <hlinnaka@iki.fi>

View thread
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Thomas Munro <thomas.munro@gmail.com>, Peter Eisentraut <peter@eisentraut.org>
Cc: Tristan Partin <tristan@neon.tech>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-14T09:54:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revert "Tidy up locale thread safety in ECPG library."

  2. Tidy up locale thread safety in ECPG library.

  3. Revert "Blind attempt to fix _configthreadlocale() failures on MinGW."

  4. Require ucrt if using MinGW.

  5. Remove configure check for _configthreadlocale().

  6. Simplify checking for xlocale.h

  7. All supported systems have locale_t.

On 14/11/2024 09:48, Thomas Munro wrote:
> On Thu, Aug 29, 2024 at 6:50 AM Peter Eisentraut <peter@eisentraut.org> wrote:
>> The error handling with pg_ensure_c_locale(), that's the sort of thing
>> I'm afraid will be hard to test or even know how it will behave.  And it
>> creates this weird coupling between pgtypeslib and ecpglib that you
>> mentioned earlier.  And if there are other users of PG_C_LOCALE in the
>> future, there will be similar questions about the proper initialization
>> and error handling sequence.
> 
> Ack.  The coupling does become at least less weird (currently it must
> be capable of giving the wrong answers reliably if called directly I
> think, no?) and weaker, but I acknowledge that it's still non-ideal
> that out-of-memory would be handled nicely only if you used ecpg
> first, and subtle misbehaviour would ensure otherwise, and future
> users face the same sort of problem unless they design in a reasonable
> initialisation place that could check pg_ensure_c_locale() nicely.
> Classic retro-fitting problem, though.

Hmm, so should we add calls to pg_ensure_c_locale() in pgtypeslib too, 
before each call to strtod_l()?

Looking at the callers of strtod() in ecpg, all but one of them actually 
readily convert the returned value to integer, with some multiplication 
or division with constants. It would be nice to replace those with a 
function that would avoid going through double in the first place. That 
still leaves one caller in numericvar_to_double() which really wants a 
double, though

Overall, the patch looks good to me.

-- 
Heikki Linnakangas
Neon (https://neon.tech)