Re: [HACKERS] wrong behavior using to_char() again

Euler Taveira de Oliveira wrote:
> Hi,
>
> Looking again at bug report [1], I agree that's a glibc bug. Numbers in
> pt_BR has its format 1.234.567,89; sometimes the format 1234567,89 is
> acceptable too, ie, the thousand separator is optional. I guess that
> some locales use the 'optional' thousand separator too (yep, they are
> all broken too).
>
> euler(at)harman:/a/pgsql$ ./a.out pt_BR
> decimal_point: ,
> thousands_sep:
> euler(at)harman:/a/pgsql$ ./a.out fr_FR
> decimal_point: ,
> thousands_sep:
> euler(at)harman:/a/pgsql$ ./a.out es_ES
> decimal_point: ,
> thousands_sep:
> euler(at)harman:/a/pgsql$ ./a.out de_DE
> decimal_point: ,
> thousands_sep: .
> euler(at)harman:/a/pgsql$ ./a.out C
> decimal_point: .
> thousands_sep:
>
> The actual behavior is set: (i) "," if the thousand separator is "" (ii)
> "." if the decimal point is "". It is not what glibc says (even in the C
> locale). I expect that PostgreSQL agrees with glibc (even it's the wrong
> behavior). Given this assumption, i propose the attached patch (it needs
> to adjust the regression tests).

OK, I researched this and realized it should have been obvious to me
when I added this code in 2006 that making the thousands separator
always "," for a locale of "" was going to cause a problem.

What I have done is to duplicate the logic we already had in
psql/print.c where the default thousands separator is either "," or "."
to make it different from the decimal separator.

I stated in the thread I would look at it for 8.3 but forgot:

http://archives.postgresql.org/pgsql-bugs/2006-09/msg00079.php

I don't think there is any change needed for the C locale. That part
seems fine, as Alvaro already pointed out.

Please test, patch attached and applied to CVS.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +