Обсуждение: wrong behavior using to_char()

Поиск
Список
Период
Сортировка

wrong behavior using to_char()

От
"Euler Taveira de Oliveira"
Дата:
Hi,

I notice a strange behavior using to_char() function. I'm using locale
pt_BR but it could happen with any locale.


template1=# select to_char(12345.67, '999G999D999');
   to_char
--------------
   12,345,670
(1 registro)

In the pt_BR locale, the thousand separator is "". So it should return
12345,670. Looking at the source, I saw that the test cases for locale
properties are independent among them. I think that the correct form is to
have all-or-nothing test case or didn't test *lconv->property ("" is
evaluated to false). Attached is a patch that fixes it using the second
option.


--
  Euler Taveira de Oliveira
  http://www.timbira.com/
Вложения

Re: wrong behavior using to_char()

От
Tom Lane
Дата:
"Euler Taveira de Oliveira" <euler@timbira.com> writes:
> In the pt_BR locale, the thousand separator is "". So it should return
> 12345,670. Looking at the source, I saw that the test cases for locale
> properties are independent among them. I think that the correct form is to
> have all-or-nothing test case or didn't test *lconv->property ("" is
> evaluated to false). Attached is a patch that fixes it using the second
> option.

Not unless you have a solution to the problem seen in this thread:
http://archives.postgresql.org/pgsql-patches/2006-02/msg00172.php

            regards, tom lane

Re: wrong behavior using to_char()

От
Bruce Momjian
Дата:
Tom Lane wrote:
> "Euler Taveira de Oliveira" <euler@timbira.com> writes:
> > In the pt_BR locale, the thousand separator is "". So it should return
> > 12345,670. Looking at the source, I saw that the test cases for locale
> > properties are independent among them. I think that the correct form is to
> > have all-or-nothing test case or didn't test *lconv->property ("" is
> > evaluated to false). Attached is a patch that fixes it using the second
> > option.
>
> Not unless you have a solution to the problem seen in this thread:
> http://archives.postgresql.org/pgsql-patches/2006-02/msg00172.php

I was going to point him to these commits to formatting.c:

    date: 2006/02/12 23:48:23;  author: momjian;  state: Exp;  lines: +3 -4
    Revert because C locale uses "" for thousands_sep, meaning "n/a", while
    French uses "" for "don't want".  Seems we have to keep the existing
    behavior.
    ----------------------------
    revision 1.105
    date: 2006/02/12 19:52:06;  author: momjian;  state: Exp;  lines: +5 -4
    Support "" for thousands separator and plus sign in to_char(), per
    report from French Debian user.  psql already handles "" fine.

One idea would be to handle C locale behavior differently from non-C
locale.

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Re: wrong behavior using to_char()

От
Peter Eisentraut
Дата:
Bruce Momjian wrote:
> One idea would be to handle C locale behavior differently from non-C
> locale.

Right.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Re: wrong behavior using to_char()

От
Euler Taveira de Oliveira
Дата:
Jorge Godoy wrote:

> > In the pt_BR locale, the thousand separator is "". So it should return
>
> The thousands separator in pt_BR is ".".
>
Oh, good catch. There is so much hack in my glibc. :-)


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

Re: wrong behavior using to_char()

От
Bruce Momjian
Дата:
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > One idea would be to handle C locale behavior differently from non-C
> > locale.
>
> Right.

I am thinking this is eomthing for 8.3.

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Re: wrong behavior using to_char()

От
Jorge Godoy
Дата:
"Euler Taveira de Oliveira" <euler@timbira.com> writes:

> In the pt_BR locale, the thousand separator is "". So it should return

The thousands separator in pt_BR is ".".

> 12345,670. Looking at the source, I saw that the test cases for locale

This should be "12.345,670".



--
Jorge Godoy      <jgodoy@gmail.com>