Sorry, I had to revert this patch. C locale uses "" as "not applicable", while French uses "" for "don't want". The C locale folks rely too much on the existing behavior.
--------------------------------------------------------------------------- pgman wrote: > > Interesting. We should be able to handle a "" thousands separator. In > fact, psql does, but to_char() does not. > > Looking at to_char(), it seems that we should be able to handle "" for > thousands and plus sign. > > I have applied the following patch for 8.2. I have not applied to 8.1.X > because it is a behavior change. > > Thanks for the report. > > --------------------------------------------------------------------------- > > Daniel Verite wrote: > > Peter Eisentraut wrote: > > > > > St?phane SCHILDKNECHT wrote: > > > > select to_char(1485.12, '9G999D99'); > > > > > > > But, surprinsingly, I got 1,1485,12. > > > > > > The fr_FR locale is broken. You should report this to glibc. > > > > On my debian sarge with LC_NUMERIC set to [EMAIL PROTECTED], a > > printf("%'g\n", 1485.12); > > produces 1485,12 with which seems to be correct given that the > > 'thousands_sep' locale entry is set to "" (empty string) and > > 'decimal_point' to U002C > > > > On the other hand, what postgres produces is: > > test=> set lc_numeric='[EMAIL PROTECTED]'; > > SET > > test=> select to_char(1485.12, '9G999D99'); > > to_char > > ----------- > > 1,485,12 > > (1 row) > > > > which is wrong with regard to thousands_sep="". > > > > In fact, grep'ing the source code reveals that, when 'thousands_sep' is set > > to > > an empty string, it gets ignored and a comma is used instead. > > I'm referring to backend/utils/adt/formatting.c, NUM_prepare_locale() in > > 8.1.2: > > > > /* > > * Number thousands separator > > */ > > if (lconv->thousands_sep && *lconv->thousands_sep) > > Np->L_thousands_sep = lconv->thousands_sep; > > else > > Np->L_thousands_sep = ","; > > > > What's wrong with lconv->thousands_sep being set to an empty string? > > Shouldn't it be used nonetheless? > > > > -- > > Daniel > > PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 9: In versions below 8.0, the planner will ignore your desire to > > choose an index scan if your joining column's datatypes do not > > match > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > Index: src/backend/utils/adt/formatting.c > =================================================================== > RCS file: /cvsroot/pgsql/src/backend/utils/adt/formatting.c,v > retrieving revision 1.104 > diff -c -c -r1.104 formatting.c > *** src/backend/utils/adt/formatting.c 12 Feb 2006 04:44:15 -0000 > 1.104 > --- src/backend/utils/adt/formatting.c 12 Feb 2006 19:48:28 -0000 > *************** > *** 3720,3734 **** > else > Np->L_negative_sign = "-"; > > ! if (lconv->positive_sign && *lconv->positive_sign) > Np->L_positive_sign = lconv->positive_sign; > else > Np->L_positive_sign = "+"; > > /* > ! * Number thousands separator > */ > ! if (lconv->thousands_sep && *lconv->thousands_sep) > Np->L_thousands_sep = lconv->thousands_sep; > else > Np->L_thousands_sep = ","; > --- 3720,3735 ---- > else > Np->L_negative_sign = "-"; > > ! /* Might be "" */ > ! if (lconv->positive_sign) > Np->L_positive_sign = lconv->positive_sign; > else > Np->L_positive_sign = "+"; > > /* > ! * Number thousands separator (might be "") > */ > ! if (lconv->thousands_sep) > Np->L_thousands_sep = lconv->thousands_sep; > else > Np->L_thousands_sep = ","; -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org