Re: INT64_MIN and _MAX - Mailing list pgsql-hackers

From Andres Freund
Subject Re: INT64_MIN and _MAX
Date
Msg-id 82CDD1EC-9E60-4D9E-914B-140880FAC4B7@anarazel.de
Whole thread Raw
In response to Re: INT64_MIN and _MAX  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: INT64_MIN and _MAX  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Re: INT64_MIN and _MAX  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On March 22, 2015 6:19:52 AM GMT+01:00, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>
>>>>>> "Petr" == Petr Jelinek <petr@2ndquadrant.com> writes:
>
>>>> So wouldn't it make more sense to move these definitions into c.h
>and
> >>> standardize their usage?
>
>Petr> I was thinking the same when I've seen Peter's version of Numeric
> Petr> abbreviations patch. So +1 for that.
>
>Hm, it looks like the same could be said for INT32_MIN and _MAX; some
>places use INT_MIN etc., others say "we shouldn't assume int = int32"
>and use (-0x7fffffff - 1) or whatever instead.

I have been annoyed by this multiple times. I think we should make sure the C99 defines are there (providing values if
theyaren't) and always use those. We've used them in parts of the tree long enough that it's unlikely to cause
problems.Nothing is helped by using different things in other parts of the tree.
 

Willing to cook up a patch?


--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Using 128-bit integers for sum, avg and statistics aggregates
Next
From: Andres Freund
Date:
Subject: Re: No toast table for pg_shseclabel but for pg_seclabel