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

On Thu, Sep 4, 2025 at 3:04 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> 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.
>
> 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.

Hmm.  So we're talking about a Debian system compiling an extension
that has these headers in its search path:

/usr/include/postgresql/postgres_ext.h <-- v18[1]
/usr/include/postgresql/17/server/postgres_ext.h <-- v17[2] (or other
older release)

I guess it's only a problem if the v17 header is found first, but such
an extension must build OK if the libpq headers are found first,
right?  I'm not sure what to think about that yet, ie how to decide
which orders should work.

Is there an argument for recommending/requiring the newer one be used?
 The counter argument must be that we could eventually remove macros
for stuff we remove in future that are still useful in the older
server that your extension is building against.  (Here we removed
something, but it's not something that matches the file's own mission
statement, it's just ancient C evolution stuff and I still think that
commit was a reasonable choice, though of course this wrinkle needs a
solution.)

Other ideas to make cross-version postgres_ext.h work, at least as far
as this issue goes:

1.  Wrap the new typedef in #ifndef PG_INT64_TYPE, with a comment to
explain that it's for older releases of postgres_ext.h that supplied
the typedef.
2.  Just delete the new typedef completely, and if someone wants it
they can define it themselves.  IIRC I couldn't actually find a single
example of another project using the typename in github or the Debian
code search.  In other words, if people are using those 3 functions
they're using some other typename, that's just how we spelled it, so
technically it may be a (noop) cast when you call them.

[1] https://packages.debian.org/trixie/amd64/libpq-dev/filelist
[2] https://packages.debian.org/trixie/amd64/postgresql-server-dev-17/filelist