| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Japin Li <japinli(at)hotmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Cannot find a working 64-bit integer type on Illumos |
| Date: | 2024-04-19 08:34:38 |
| Message-ID: | 1a0cc462-5619-47ef-bad9-06b96b2f277f@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18.04.24 02:31, Thomas Munro wrote:
> For limits, why do we have this:
>
> - * stdint.h limits aren't guaranteed to have compatible types with our fixed
> - * width types. So just define our own.
>
> ? I mean, how could they not have compatible types?
The commit for this was 62e2a8dc2c7 and the thread was
<https://www.postgresql.org/message-id/flat/E1YatAv-0007cu-KW%40gemulon.postgresql.org>.
The problem was that something like
snprintf(bufm, sizeof(bufm), INT64_FORMAT, SEQ_MINVALUE);
could issue a warning if, say, INT64_FORMAT, which refers to our own
int64, is based on long int, but SEQ_MINVALUE, which was then INT64_MIN,
which refers to int64_t, which could be long long int.
So this is correct. If we introduce the use of int64_t, then you need
to be consistent still:
int64, PG_INT64_MIN, PG_INT64_MAX, INT64_FORMAT
int64_t, INT64_MIN, INT64_MAX, PRId64
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2024-04-19 08:45:45 | Re: Idea Feedback: psql \h misses -> Offers Links? |
| Previous Message | shveta malik | 2024-04-19 08:22:18 | Re: promotion related handling in pg_sync_replication_slots() |