Re: Centralize use of PG_INTXX_MIN/MAX for integer limits - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Centralize use of PG_INTXX_MIN/MAX for integer limits
Date
Msg-id 87ftvqqi2p.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Centralize use of PG_INTXX_MIN/MAX for integer limits  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
>>>>> "Michael" == Michael Paquier <michael@paquier.xyz> writes:

 Michael> Hi all,

 Michael> A couple of years ago, 62e2a8dc has introduced in c.h a set of
 Michael> limits (to fix some portability issues from 83ff1618) to make
 Michael> the code more system-independent. Those are for example
 Michael> PG_INT32_MIN, etc. The core code now mixes the internal PG_
 Michael> limits with the system ones. Would we want to unify a bit the
 Michael> whole thing and replace all the SHRT_MIN/MAX, LONG_MIN/MAX and
 Michael> such with the internal limit definitions?

Of course not. And LONG_MIN/MAX is the obvious example of why not, since
that one does vary between platforms.

INT_MAX is for the max value of an "int". PG_INT32_MAX is for the max
value of an "int32". PG_INT64_MAX is for the max value of an "int64".
LONG_MAX is for the max value of a "long". Simple.

However, as I said at the time of those patches, I did not at that stage
audit all the uses of INT_MIN/MAX to determine which should really have
been INT32_MIN/MAX. Currently, all sorts of things will likely break if
"int" and "int32" are not exactly the same size, but it might still be a
good idea to fix that at some point. (As a recent example,
contrib/intarray uses "int" almost universally, regardless of the fact
that it's meant to be dealing with SQL "integer" values, which should be
int32.)

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Desirability of client-side expressions in psql?
Next
From: Peter Geoghegan
Date:
Subject: Re: Making all nbtree entries unique by having heap TIDs participatein comparisons