Re: Cannot find a working 64-bit integer type on Illumos
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Japin Li <japinli@hotmail.com>, Andres Freund <andres@anarazel.de>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-23T02:23:13Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > . o O ( int64_t, PRIdi64, etc were standardised a quarter of a century ago ) Yeah. Now that we require C99 it's probably reasonable to assume that those things exist. I wouldn't be in favor of ripping out our existing notations like UINT64CONST, because the code churn would be substantial and the gain minimal. But we could imagine reimplementing that stuff atop <stdint.h> and then getting rid of the configure-time probes. regards, tom lane
Commits
-
Move pg_int64 back to postgres_ext.h
- e56a601e0678 19 (unreleased) landed
- 409543da5411 18.0 landed
-
pgbench: Make set_random_seed() 64-bit everywhere.
- 53a2a1564ae4 18.0 landed
-
Use PRI?64 instead of "ll?" in format strings (continued).
- a0ed19e0a9ef 18.0 landed
-
Fix order of -I switches for building pg_regress.o.
- f186f90e55b7 17.5 landed
- cb36f8ec2124 18.0 landed
-
libpq: Deprecate pg_int64.
- 3c86223c9982 18.0 landed
-
Use PRI*64 instead of "ll*" in format strings (minimal trial)
- 15a79c73111f 18.0 landed
-
Fix header inclusion order in c.h.
- 71cb352904c1 18.0 landed
-
Use <stdint.h> and <inttypes.h> for c.h integers.
- 962da900ac8f 18.0 landed
-
Remove traces of BeOS.
- a2d9a9b95ad9 18.0 landed
-
More correct way to check for existence of types, which allows to specify
- 15abc7788e66 7.2.1 cited