wrong behavior using to_char() again - Mailing list pgsql-hackers

From Euler Taveira de Oliveira
Subject wrong behavior using to_char() again
Date
Msg-id 473F46D1.10605@timbira.com
Whole thread Raw
Responses Re: wrong behavior using to_char() again  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Hi,

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 that
some locales use the 'optional' thousand separator too (yep, they are
all broken too).

euler@harman:/a/pgsql$ ./a.out pt_BR
decimal_point: ,
thousands_sep:
euler@harman:/a/pgsql$ ./a.out fr_FR
decimal_point: ,
thousands_sep:
euler@harman:/a/pgsql$ ./a.out es_ES
decimal_point: ,
thousands_sep:
euler@harman:/a/pgsql$ ./a.out de_DE
decimal_point: ,
thousands_sep: .
euler@harman:/a/pgsql$ ./a.out C
decimal_point: .
thousands_sep:

The actual behavior is set: (i) "," if the thousand separator is "" (ii)
"." if the decimal point is "". It is not what glibc says (even in the C
locale). I expect that PostgreSQL agrees with glibc (even it's the wrong
behavior). Given this assumption, i propose the attached patch (it needs
to adjust the regression tests).

Comments?


[1] http://archives.postgresql.org/pgsql-bugs/2006-09/msg00074.php


--
  Euler Taveira de Oliveira
  http://www.timbira.com/
#include <stdio.h>
#include <locale.h>

int main(int argc, char *argv[])
{
    struct lconv *x;
    char *lang;

    if (argc == 2)
        lang = argv[1];
    else
        lang = "C";

    setlocale(LC_NUMERIC, (const char *) lang);
    x = localeconv();

    printf("decimal_point: %s\n", x->decimal_point);
    printf("thousands_sep: %s\n", x->thousands_sep);

    return 0;
}
*** src/backend/utils/adt/formatting.c.orig    2007-11-16 01:34:41.000000000 -0200
--- src/backend/utils/adt/formatting.c    2007-11-17 17:30:00.000000000 -0200
***************
*** 3917,3931 ****

          /*
           * Number thousands separator
-          *
-          * Some locales (e.g. broken glibc pt_BR), have a comma for
-          * decimal, but "" for thousands_sep, so we might make the
-          * thousands_sep comma too.  2007-02-12
           */
          if (lconv->thousands_sep && *lconv->thousands_sep)
              Np->L_thousands_sep = lconv->thousands_sep;
          else
!             Np->L_thousands_sep = ",";

          /*
           * Currency symbol
--- 3917,3927 ----

          /*
           * Number thousands separator
           */
          if (lconv->thousands_sep && *lconv->thousands_sep)
              Np->L_thousands_sep = lconv->thousands_sep;
          else
!             Np->L_thousands_sep = "";

          /*
           * Currency symbol
***************
*** 3943,3949 ****
          Np->L_negative_sign = "-";
          Np->L_positive_sign = "+";
          Np->decimal = ".";
!         Np->L_thousands_sep = ",";
          Np->L_currency_symbol = " ";
      }
  }
--- 3939,3945 ----
          Np->L_negative_sign = "-";
          Np->L_positive_sign = "+";
          Np->decimal = ".";
!         Np->L_thousands_sep = "";
          Np->L_currency_symbol = " ";
      }
  }

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: VACUUM/ANALYZE counting of in-doubt tuples
Next
From: Matthew Grosso
Date:
Subject: offtopic, historic, in 8.1, how to find relfrozenxid by table?