Re: Zero-padding and zero-masking fixes for to_char(float)
От | Bruce Momjian |
---|---|
Тема | Re: Zero-padding and zero-masking fixes for to_char(float) |
Дата | |
Msg-id | 20150323030045.GD19951@momjian.us обсуждение исходный текст |
Ответ на | Re: Zero-padding and zero-masking fixes for to_char(float) (Bruce Momjian <bruce@momjian.us>) |
Список | 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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: