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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: tester357 <tester357(dot)postgres(at)email(dot)cz>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #16512: Character considered as a number by regex but can not convert to numeric
Date: 2020-07-09 20:29:11
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

tester357 <tester357(dot)postgres(at)email(dot)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

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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2020-07-10 01:53:54 Re: BUG #16526: pg_test_fsync in v12 doesn't run in Windows
Previous Message Tom Lane 2020-07-09 20:09:41 Re: Getting Error while using row_number()