mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-01-06 15:24:56 +08:00
35d50b527a
The existing code in NUM_numpart_from_char has hard-wired logic to treat '.' as decimal point, even when we're using a locale-aware format string and the locale says that '.' is the thousands separator. This results in clearly wrong answers in FM mode (where we must be able to identify the decimal point location), as per bug report from Patryk Kordylewski. Since the initialization code in NUM_prepare_locale already sets up Np->decimal as either the locale decimal-point string or "." depending on which decimal-point format code was used, there's really no need to have any extra logic at all in NUM_numpart_from_char: we only need to test for a match to Np->decimal. (Note: AFAICS there's nothing in here that explicitly checks for thousands separators --- rather, any unmatched character is silently skipped over. That's pretty bogus IMO but it's not the issue being complained of.) This is a longstanding bug, but it's possible that some existing apps are depending on '.' being recognized as decimal point even when using a D format code. Hence, no back-patch. We should probably list this as a potential incompatibility in the 9.3 release notes. |
||
---|---|---|
.. | ||
backend | ||
bin | ||
common | ||
include | ||
interfaces | ||
makefiles | ||
pl | ||
port | ||
template | ||
test | ||
timezone | ||
tools | ||
tutorial | ||
.gitignore | ||
bcc32.mak | ||
DEVELOPERS | ||
Makefile | ||
Makefile.global.in | ||
Makefile.shlib | ||
nls-global.mk | ||
win32.mak |