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)
