Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

pgsql-hackers by date

Next:From: Oleg BartunovDate: 2005-06-01 05:48:14
Subject: Re: Deadlock with tsearch2 index ...
Previous:From: Neil ConwayDate: 2005-06-01 05:00:04
Subject: Re: NOLOGGING option, or ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group