Re: wrong behavior using to_char() again

Поиск
Список
Период
Сортировка
От Euler Taveira de Oliveira
Тема Re: wrong behavior using to_char() again
Дата
Msg-id 47464EDB.2020607@timbira.com
обсуждение исходный текст
Ответ на wrong behavior using to_char() again  (Euler Taveira de Oliveira <euler@timbira.com>)
Ответы Re: wrong behavior using to_char() again  (Bruce Momjian <bruce@momjian.us>)
Re: [PATCHES] wrong behavior using to_char() again  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
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 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@harman:/a/pgsql$ ./a.out C
decimal_point: "."
thousands_sep: ""
euler@harman:/a/pgsql$ ./a.out en_US
decimal_point: "."
thousands_sep: ","

[1] http://timbira.com/tmp/lcn3.sql
[2] http://timbira.com/tmp/lcnumeric.diff


--
  Euler Taveira de Oliveira
  http://www.timbira.com/

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: Autovacuum and OldestXmin
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: wrong behavior using to_char() again