| 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: | Whole Thread | Raw Message | 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 |