Re: [HACKERS] wrong behavior using to_char() again - Mailing list pgsql-patches

From Alvaro Herrera
Subject Re: [HACKERS] wrong behavior using to_char() again
Date
Msg-id 20071123111037.GA4771@alvh.no-ip.org
Whole thread Raw
In response to Re: [HACKERS] wrong behavior using to_char() again  (Euler Taveira de Oliveira <euler@timbira.com>)
List 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)

pgsql-patches by date:

Previous
From: "Marko Kreen"
Date:
Subject: Cleaner API for appendStringInfoVA
Next
From: Hannes Eder
Date:
Subject: parse_expr.c:typecast_expression:return immediate on NULL input