From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] wrong behavior using to_char() again |
Date: | 2007-11-23 11:10:37 |
Message-ID: | 20071123111037.GA4771@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Dragan Zubac | 2007-11-23 11:31:59 | Transaction question |
Previous Message | Simon Riggs | 2007-11-23 10:24:54 | Re: Test lab |
From | Date | Subject | |
---|---|---|---|
Next Message | Hannes Eder | 2007-11-23 11:44:19 | parse_expr.c:typecast_expression:return immediate on NULL input |
Previous Message | Marko Kreen | 2007-11-23 09:55:22 | Cleaner API for appendStringInfoVA |