From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Define integer limits independently from the system definitions. |
Date: | 2015-10-19 14:51:22 |
Message-ID: | CAB7nPqTwN+HFUfZNMMJuWL6TquWEoVtfutvAQN9HMKOGYDUrTw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Hi Andres,
On Fri, Apr 3, 2015 at 12:45 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Define integer limits independently from the system definitions.
>
> In 83ff1618 we defined integer limits iff they're not provided by the
> system. That turns out not to be the greatest idea because there's
> different ways some datatypes can be represented. E.g. on OSX PG's 64bit
> datatype will be a 'long int', but OSX unconditionally uses 'long
> long'. That disparity then can lead to warnings, e.g. around printf
> formats.
>
This commit has added PG_INT16_MIN/MAX, however we still rely on SHRT_MIN
and SHRT_MAX in some code paths. On all the platforms I looked at (OpenBSD,
FreeBSD, MinGW, MSVC, OSX, Linux, Solaris) SHRT_MIN and SHRT_MAX
definitions are always the same. Still, shouldn't we replace SHRT_* by
their equivalent PG_INT16_* to be completely independent? I am just
wondering if you considered that.
Regards,
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-10-19 20:55:14 | pgsql: Fix incorrect handling of lookahead constraints in pg_regprefix( |
Previous Message | Michael Meskes | 2015-10-18 08:17:33 | pgsql: Fix order of arguments in ecpg generated typedef command. |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-10-19 15:13:28 | Re: pg_restore cancel TODO |
Previous Message | Alvaro Herrera | 2015-10-19 14:51:00 | Re: pg_restore cancel TODO |