Re: wrong behavior using to_char() again

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? 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 am confused. You stated in your earlier email:

> 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

so I assumed that you were OK with having "." be the thousands
separator. I think we have to try to get a proper fix even if glibc is
incorrect. The problem we had with psql print.c is that when we didn't
provide a "." default we had people complaining about that. The idea I
think is that if people are asking for a thousands separator in the
to_char() format they certainly want to see a thousands separator.

The backend behavior now matches the psql numericlocale behavior which
was accepted a while back.

> > 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(at)harman:/a/pgsql$ ./a.out C
> decimal_point: "."
> thousands_sep: ""
> euler(at)harman:/a/pgsql$ ./a.out en_US
> decimal_point: "."
> thousands_sep: ","

Yes, I think that is correct.

--
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. +