Horton

Re: Cannot find a working 64-bit integer type on Illumos

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tomas Vondra <tomas@vondra.me>, Heikki Linnakangas <hlinnaka@iki.fi>, Japin Li <japinli@hotmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-03T15:04:03Z
Lists: pgsql-hackers 
On 10.12.24 03:02, Thomas Munro wrote:
> And if we included <stdint.h> overtly, rather than covertly in
> postgres_ext.h, why would we still want a third name for int64_t?  We
> could change the three lo_*64() declarations to use the standard type
> directly, but keep the historical typedef marked deprecated.
> 
>> But I don't see a strong argument to
>> change long-standing external APIs any more than we absolutely must.
> 
> So perhaps you'll hate that idea then.  I wonder if you'll hate it
> more than keeping the #include in postgres_ext.h, hence putting the
> idea forward!

This change in commit 3c86223c998 is problematic.

commit 3c86223c998
Author: Thomas Munro <tmunro@postgresql.org>
Date:   Tue Mar 25 08:17:53 2025

     libpq: Deprecate pg_int64.

     ...

     Keep a typedef marked deprecated for backward compatibility, but 
move it
     into libpq-fe.h where it was used.


Consider a third-party extension that does something like dblink or 
postgres_fdw.  It will compile against a server and also a libpq.  The 
server and the libpq might not be of the same major version.  (On 
Debian, only the latest libpq will be available.)  If you have for 
example server version 17 and libpq version 18, then you will get the 
pg_int64 typedef both from postgres_ext.h (from the PG17 server 
includes) and from libpq-fe.h (from PG18 libpq).  That is not allowed in 
C99, and even if it were, the underlying types of PG_INT64_TYPE (in 
PG17) and int64_t (in PG18) might be different (long int vs. long long 
int) and this would fail.

I think this could be fixed by moving the definition of pg_int64 back to 
postgres_ext.h.  Then extension builds would only get one definition, 
because of the header guards.  Depending on include order, they could 
get a different underlying type, but that's a smaller problem, since the 
type is supposed to be deprecated anyway.

Commits

  1. Move pg_int64 back to postgres_ext.h

  2. pgbench: Make set_random_seed() 64-bit everywhere.

  3. Use PRI?64 instead of "ll?" in format strings (continued).

  4. Fix order of -I switches for building pg_regress.o.

  5. libpq: Deprecate pg_int64.

  6. Use PRI*64 instead of "ll*" in format strings (minimal trial)

  7. Fix header inclusion order in c.h.

  8. Use <stdint.h> and <inttypes.h> for c.h integers.

  9. Remove traces of BeOS.

  10. More correct way to check for existence of types, which allows to specify