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>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-04T09:05:03Z
Lists: pgsql-hackers 
On 04.09.25 02:39, Thomas Munro wrote:
> 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.

The logs I have seen have the libpq include path first.

I don't think the order matters.  The problem is that you have two 
conflicting typedefs of the same name in two separate header files.  So 
if you include both of them, you'll get an error.

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