On 10-05-2013 13:09, Thomas Kellerer wrote: > Tom Lane wrote on 10.05.2013 17:49: >> I looked into this, and find that the reason it misbehaves is that >> NUM_numpart_from_char() will treat a '.' as being a decimal point >> *without any regard to locale considerations*. So even if we have >> a locale-dependent format string and a locale that says '.' is a >> thousands separator, it does the wrong thing. >> >> It's a bit surprising nobody's complained of this before. >> >> I propose the attached patch. I'm slightly worried though about whether >> this might break any existing applications that are (incorrectly) >> depending on a D format specifier being able to match '.' regardless of >> locale. Perhaps we should only apply this to HEAD and not back-patch? > +1 only in HEAD. That's because (a) it doesn't crash, (b) it doesn't always produce the "wrong" answer (only in some specific situation) and (c) it has been like that for years without a complain. For those reasons, it is better to continue with this "wrong" behavior in back branches than prevent important security updates to be applied (without applying a patch to preserve the "wrong" answer). This argument is only valid for legacy closed-source apps but seems to have more weight than the bug scenario.
> The manual claims that 'D' is locale dependent (whereas '.' is not), so > _theoretically_ a back patch would make sense I guess. > I would consider a documentation bug in back branches because fix it means break apps. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
