Re: WIP: to_char, support for EEEE format

2009/8/9 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Brendan Jurd <direvus(at)gmail(dot)com> writes:
>> That would allow for a maximum of 10 exponent digits.  As an aside, I
>> note that int4out() hardcodes the maximum number of digits rather than
>> exposing a constant (c.f. MAXINT8LEN in int8.c).  I'm considering
>> adding MAXINT2LEN and MAXINT4LEN to int.c in passing.  Excessive
>> tinkering, or worthy improvement?
>
> Don't really care.  short and int are the same sizes on all platforms of
> interest, and are likely to remain so --- if they don't, we'll have way
> more places to fix than this one.  INT8 has historically been more
> platform-dependent.
>

"Excessive tinkering" it is, then. I went ahead with hardcoding the
expected 10 digits.

Here's version 6 of the EEEE patch, now with an all-new implementation
of (normalised) scientific notation in numeric.c, via the functions
numeric_out_sci() and get_str_from_var_sci(). So EEEE should now be
able to represent the full gamut of the numeric type.

regression=# select to_char(-1e-1000, '9.99EEEE');
to_char
-------------
-1.00e-1000
(1 row)

I also noticed that EEEE wasn't outputting a leading space for
positive numbers like the rest of to_char does. This meant that
positive and negative numbers weren't aligned. The logic to do this
for ordinary decimal representations is tied up in NUM_processor() and
NUM_numpart_to_char(), so unfortunately I wasn't able to reuse it.
Instead I just frobbed the code in the *_to_char() functions to make
this work.

Noting that Robert has dropped the patch from the July CF (and having
no objection to that) I'm going to submit this for September.

Cheers,
BJ