SEO

#1 (**permalink**) 04-19-2008, 06:23 AM

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@harman:/a/pgsql$ ./a.out pt_BR
> decimal_point: ,
> thousands_sep:
> euler@harman:/a/pgsql$ ./a.out fr_FR
> decimal_point: ,
> thousands_sep:
> euler@harman:/a/pgsql$ ./a.out es_ES
> decimal_point: ,
> thousands_sep:
> euler@harman:/a/pgsql$ ./a.out de_DE
> decimal_point: ,
> thousands_sep: .
> euler@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...9/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@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

#2 (**permalink**) 04-19-2008, 06:23 AM

Bruce Momjian wrote:

> 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.
>
I tested your patch and IMHO it breaks the glibc behavior. I'm providing
a SQL script [1] and a diff [2] showing the differences between before
and after applying it. In [2], I see a lot of common used (pt_*, es_*,
and fr_*) locales that we'll be changed. Is it the behavior we want to
support? I think we shouldn't try to fix glibc bug inside PostgreSQL (in
this case, use should accept "" as a possible value for thousands_sep).

> I don't think there is any change needed for the C locale. That part
> seems fine, as Alvaro already pointed out.
>
I don't know about C locale, but it's broken too. In PostgreSQL, it's
following the en_US behavior. Comments?

euler@harman:/a/pgsql$ ./a.out C
decimal_point: "."
thousands_sep: ""
euler@harman:/a/pgsql$ ./a.out en_US
decimal_point: "."
thousands_sep: ","

[1] http://timbira.com/tmp/lcn3.sql
[2] http://timbira.com/tmp/lcnumeric.diff

--
Euler Taveira de Oliveira
http://www.timbira.com/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

#3 (**permalink**) 04-19-2008, 06:23 AM

Euler Taveira de Oliveira wrote:
> Bruce Momjian wrote:
>
> > 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.
> >
> I tested your patch and IMHO it breaks the glibc behavior. I'm providing
> a SQL script [1] and a diff [2] showing the differences between before
> and after applying it. In [2], I see a lot of common used (pt_*, es_*,
> and fr_*) locales that we'll be changed. Is it the behavior we want to
> support?

Well, what I can say is that the behavior you show for es_* that we were
historically doing is quite wrong, and the corrected output looks
better.

lc_numeric | to_char
------------+------------------------
! es_CL | 123,456,789,01230
(1 registro)

--- 379,397 ----

SET
lc_numeric | to_char
------------+------------------------
! es_CL | 123.456.789,01230
(1 registro)

The first output makes no sense whereas the second is correct (ISTM
we've been doing it wrong for a lot of locales and it has just been
fixed).

--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"No deja de ser humillante para una persona de ingenio saber
que no hay tonto que no le pueda enseñar algo." (Jean B. Say)

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

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