On Mon, Sep 23, 2019 at 11:57:47AM +0200, Michael Weiser wrote:
> OTOH: If we can be *really* certain about the format generated by
> Postgres we might be able to get away with a very reduced version of
> strtod_l(). A generic implementation deals with a number of different
> formats such as 1.2e12, 0x prefix for hex base, infinity, nan and so on
> which postgres might never generate.
PostgreSQL doesn't emit 0x here, but it does emit the others.
> I'm really starting to wonder if solving a problem that's already been
> solved by perl itself is worth the effort. If only Apple were to update
> their system perl once every five years or so we'd be golden.
Yeah, it may not be worth it. DBD::Pg could just assert that DBD::Pg 3.6.0
(released 2017-04-17) and later require Perl 5.22 (released 2015-01-01, out of
support 2017-05-30) or later.
Another possibility is to disable the strtod() call when building against older
Perl; instead, use sv_setpv() to store the float as a string. Perl would
convert to a number when used arithmetically. For implicit conversion of
strings to numbers, Perl seems to recognize "." as the radix character
regardless of locale:
$ LANG=de_DE.UTF-8 perl -MPOSIX -e 'use strict; use warnings;
setlocale(LC_NUMERIC, ""); print join " ", (1.1 + "2.2"), (3.1 + "4,4"),
strtod("1.1"), "\n"'
Argument "4,4" isn't numeric in addition (+) at -e line 1.
3,3 7,1 1 2
Does that approach have material disadvantages?
