From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Glaesemann <grzm(at)myrealbox(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Interval->day proposal |
Date: | 2005-06-01 05:09:32 |
Message-ID: | 10175.1117602572@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Glaesemann <grzm(at)myrealbox(dot)com> writes:
> On May 31, 2005, at 12:48 AM, Tom Lane wrote:
>> Actually, practically all of the Postgres code assumes int is at least
>> 32 bits. Feel free to change pg_tm's field to be declared int32
>> instead
>> of just int if that bothers you, but it is really quite academic.
> Thanks for the clarification. My instinct would be to change so that
> it's no longer just an assumption. Is there any benefit to changing
> the other pg_tm int fields to int32? I imagine int is used quite a
> bit throughout the code, and I'd think assuming 32-bit ints would
> have bitten people in the past if it were invalid, so perhaps
> changing them is unnecessary.
As I understand it, the received wisdom of the C community is that
"int" means the machine's natural, most efficient word width. The
C specification was written at a time when a fair percentage of hardware
thought that meant int16 (and I do remember programming such hardware).
But there are no longer any machines ... or at least none on which you'd
want to run Postgres ... for which int means int16; today I'd assume
that int means "probably int32, maybe int64 if that's really faster
on this machine".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2005-06-01 05:48:14 | Re: Deadlock with tsearch2 index ... |
Previous Message | Neil Conway | 2005-06-01 05:00:04 | Re: NOLOGGING option, or ? |