Re: BUG #16512: Character considered as a number by regex but can not convert to numeric

tester357 <tester357.postgres@email.cz> writes:
> Behavior has been tested on both Postgresql 10 and Postgresql 12 with same
> LC_CTYPE set. Actualy it was the same Windows computer.
> The problem might be fixed by using [0-9\.]+ but it does not explain the
> different behaviour among Postgres versions.

True.  If the older version were pre-v10 the explanation would be that it
lacked support for regex character-class checks on characters above U+7FF.
But AFAICS, we should act the same in v10 and later versions: we just ask
the platform's iswdigit() whether the character is a digit.  I have to
conclude there's something inconsistent in iswdigit().

I notice that POSIX seems to mandate that the [:digit:] class be
exactly '0' through '9': the "Locale" chapter says

digit
    Define the characters to be classified as numeric digits.

    In the POSIX locale, only:
    0 1 2 3 4 5 6 7 8 9
    shall be included.

    In a locale definition file, only the digits <zero>, <one>, <two>,
    <three>, <four>, <five>, <six>, <seven>, <eight>, and <nine> shall
    be specified, and in contiguous ascending sequence by numerical
    value. The digits <zero> to <nine> of the portable character set
    are automatically included in this class.

The Linux man page for iswdigit() says the same, so it's no surprise
that the test case returns "false" on Linux.  Sadly, it's also little
surprise if Microsoft thinks they're not bound by the POSIX spec.

In general, I'm not finding anything particularly investigation-worthy
in this report.  If somebody with an appropriate system wanted to chase
down exactly why the v10 vs v12 difference exists, that might be
marginally interesting, but I doubt we'd consider it a bug.
Platform-dependent results are expected here.

            regards, tom lane