Re: BUG #6217: to_char() gives incorrect output for very small float values

Greg Stark <stark@mit.edu> writes:
> On Tue, Sep 20, 2011 at 8:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> However, it would
>> be interesting to know what Oracle etc do with NaN and Infinity,
>> assuming they even support such numbers.

> Note that it looks like NUMBER cannot store either Infinity or NaN.
> They can only occur in BINARY_FLOAT and BINARY_DOUBLE. From the docs:

>> If a BINARY_FLOAT or BINARY_DOUBLE value is converted to CHAR or NCHAR, and the input is either infinity or NaN (not
anumber), then Oracle always returns the pound signs to replace the value. 

> And testing shows:

> SQL> select to_char(cast('NAN' as binary_float), 'FM9999.9999') from dual;

> TO_CHAR(CA
> ----------
> ##########

Hmm, interesting.  They replace the whole field with '#', not just the
digit positions?  Because that's not what is happening in our code at
the moment, for the one case where we consider this at all:

regression=# select to_char('nan'::float8, '9999.9999EEEE');
    to_char
----------------
  ####.########
(1 row)

The EEEE path seems rather broken in some other ways as well:

regression=# select to_char('43.5'::float8, '9999.9999EEEE');
   to_char
-------------
  4.3500e+01
(1 row)

Since I did not say FM, why is it suppressing leading spaces here?

I'm starting to think that that code needs a wholesale rewrite
(not but what that's true of just about every part of formatting.c).

            regards, tom lane