Re: wrong behavior using to_char() again

Euler Taveira de Oliveira wrote:
> Bruce Momjian wrote:
>
> > 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.
> >
> Maybe I'm not so clear (too few caffeine) but what I tried to say
> (suggest) is that we could accept the thousands_sep from glibc instead
> of guessing it ("."). I'm fine with the current behavior (at least in
> pt_BR) but I'm afraid we have broken some locales (those that a
> presented in the lcnumeric.diff).

Yea, I am afraid we will have to wait for feedback during 8.3 to see.
We did hammer out the psql behavior with quite a bit of discussion so I
am hopeful doing the same in the backend will help. The new code is
certainly better than what was there before because no one wants the
thousands separator to be the same as the decimal point, so at least
that is a fix, and it seems better for your language. Basically we have
never treated "" as no thousands separator and I don't remember anyone
asking for that behavior.

If we want to start honoring "" as really no thousands separator we are
going to have to have additional discussion and go back and read from
the many people who complained when we had that behavior. I know most
people didn't like the C locale having "" for thousands separator so we
had to hard-code that.

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