Re: wrong behavior using to_char() again
| От | Euler Taveira de Oliveira |
|---|---|
| Тема | Re: wrong behavior using to_char() again |
| Дата | |
| Msg-id | 47465C6C.7000306@timbira.com обсуждение исходный текст |
| Ответ на | Re: wrong behavior using to_char() again (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: wrong behavior using to_char() again
|
| Список | pgsql-hackers |
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).
-- Euler Taveira de Oliveira http://www.timbira.com/
В списке pgsql-hackers по дате отправления: