Re: Zero-padding and zero-masking fixes for to_char(float)

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Zero-padding and zero-masking fixes for to_char(float)
Date: 2015-03-23 03:00:45
Message-ID: 20150323030045.GD19951@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 22, 2015 at 10:53:12PM -0400, Bruce Momjian wrote:
> > > *************** int4_to_char(PG_FUNCTION_ARGS)
> > > *** 5214,5221 ****
> > > /* we can do it easily because float8 won't lose any precision */
> > > float8 val = (float8) value;
> > >
> > > ! orgnum = (char *) palloc(MAXDOUBLEWIDTH + 1);
> > > ! snprintf(orgnum, MAXDOUBLEWIDTH + 1, "%+.*e", Num.post, val);
> > >
> > > /*
> > > * Swap a leading positive sign for a space.
> > > --- 5207,5213 ----
> > > /* we can do it easily because float8 won't lose any precision */
> > > float8 val = (float8) value;
> > >
> > > ! orgnum = psprintf("%+.*e", Num.post, val);
> >
> > Neither the submission notes nor the commit messages mentioned it, but this
> > improves behavior for to_char(int4, text). Specifically, it helps EEEE
> > formats with more than about 500 decimal digits:
> >
> > SELECT length(to_char(1, '9D' || repeat('9', 800) || 'EEEE'));
>
> Wow, that is surprising.

Ah, yes. There was a problem where were clipping off int4 EEEE output
to MAXDOUBLEWIDTH, which made no sense, so there was the fix for that as
well.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-03-23 03:46:45 Re: New functions
Previous Message Amit Khandekar 2015-03-23 02:55:01 Re: Resetting crash time of background worker