Re: Interval->day proposal

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

In response to

Browse pgsql-hackers by date

  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 ?