Greg Stark <st...@mit.edu> writes:
> On Tue, Sep 20, 2011 at 8:52 PM, Tom Lane <t...@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 a number), 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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
