Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] Number format problem

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: pgman(at)candle(dot)pha(dot)pa(dot)us
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [GENERAL] Number format problem
Date: 2006-02-12 23:50:12
Message-ID: 200602122350.k1CNoCo13594@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
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 fr_FR(at)euro, 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='fr_FR(at)euro';
> > 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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-patches by date

Next:From: Tom LaneDate: 2006-02-12 23:51:00
Subject: Re: [GENERAL] Number format problem
Previous:From: Bruce MomjianDate: 2006-02-12 23:45:12
Subject: Re: [GENERAL] Number format problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group