2009/8/9 Tom Lane <t...@sss.pgh.pa.us>: > Brendan Jurd <dire...@gmail.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
EEEE_6.diff.bz2
Description: BZip2 compressed data
EEEE_5-to-6.diff.bz2
Description: BZip2 compressed data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
