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

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(at)postgresql(dot)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.