On 14/11/2024 09:48, Thomas Munro wrote:
On Thu, Aug 29, 2024 at 6:50 AM Peter Eisentraut <pe...@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)
