From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brendan Jurd <direvus(at)gmail(dot)com> |
Cc: | Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: to_char, support for EEEE format |
Date: | 2009-08-08 16:06:50 |
Message-ID: | 16242.1249747610@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Brendan Jurd <direvus(at)gmail(dot)com> writes:
> 2009/8/3 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Uh, no, we had better support more. The actual limit of the current
>> numeric format is 1e+131072.
> Given your comment above I'm thinking it reasonable to use an int32 to
> store the exponent -- will that be safe?
Seems reasonable to me.
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-08-08 16:15:32 | Re: hot standby - merged up to CVS HEAD |
Previous Message | Boszormenyi Zoltan | 2009-08-08 15:58:11 | Re: Split-up ECPG patches |