Subject: libpq version macro to use or not PQsocketPoll

From: Dominique Devienne <[email-masked]>
Date: Tue, 6 Aug 2024 15:28:21 +0200

Hi. Now that v17beta2 is part of my dev-env, I'm trying out the new API.
And I discover there's no version macro for conditional compilation in LIBPQ...

I found https://www.postgresql.org/message-id/968815.1623936849%40sss.pgh.pa.us
where Tom thinks that a horrible idea, and instead proposes a new
_HAS_ flag instead.
Except of course there's on such flag for the new PQsocketPoll in beta2...
I see only 3 such _HAS_ flags.

I'm not sure what's so wrong with version macro as such.
- GCC has one.
- [SQLite has one][1].
- Why can't LIBPQ have one?

That's exactly the kind of issues they are designed to solve for code
that needs to be portable across versions. What am I missing?

Thanks, --DD

[1]: https://www.sqlite.org/c3ref/c_source_id.html

---

From: Tom Lane <[email-masked]>
Date: Tue, 06 Aug 2024 10:31:04 -0400

> And I discover there's no version macro for conditional compilation in LIBPQ...

Indeed, that's an oversight, and there's a number of other things
we added to libpq-fe.h between 16 and 17 that probably deserve
their own LIBPQ_HAS symbols.

> I'm not sure what's so wrong with version macro as such.

A couple of things:
* It doesn't help if we forget to update it, so it's not really
  better than HAS_ symbols on that score.
* Usage is error-prone (you might test for the wrong cutoff version)
  and not very readable.
* We can't retroactively make such a symbol appear in old copies
  of libpq-fe.h.

			regards, tom lane

---

From: Dominique Devienne <[email-masked]>
Date: Tue, 6 Aug 2024 16:48:00 +0200

> their own LIBPQ_HAS symbols.

OK, thanks. Glad to know they'll be in beta3 or the final release.

>   better than HAS_ symbols on that score.

I think it's easier to track/spot as part of the release process,
and probably even automate it (or its checking).

It's also a very common practice.
If DRH does it for SQLite, then it has to be OK :)

> * Usage is error-prone (you might test for the wrong cutoff version)

That's the client's responsibility.
The "vendor" just has to increment/update the macros on every release.

> * We can't retroactively make such a symbol appear in old copies

Sure. But we can start at some point. And eventually assume
the macros exist, because older versions w/o them are no longer
supported by your client code. And each client code base decides that.

Again, the "vendor" just has to start defining the macros,
and keep updating them. That's all. The rest is up to the client.

My $0.02. I can use _HAS_ flags too.

They are orthogonal in the first place, in fact.
We can have both. Also, version macros don't
multiply the way _HAS_ macros do, over time.

It's neve too late to start adding them :). --DD

---

From: Dominique Devienne <[email-masked]>
Date: Fri, 9 Aug 2024 15:49:33 +0200

> > their own LIBPQ_HAS symbols.

Hi. Doesn't look like beta3 _has_ them (pun indented :)).
Was probably too late for the beta3 release train.

> multiply the way _HAS_ macros do, over time.

I stumbled on such version macros today by chance.
And pg_config.h seems available on both Windows and Linux.
So I guess that's good enough for conditional compilation.

>From the old post I found, and your recent reply Tom,
I got the impression these macros didn't exist. FWIW. --DD

[ddevienne@acme include]$ sift VERSION pg*.h
pg_config.h:#define PACKAGE_VERSION "16.1"
pg_config.h:#define PG_MAJORVERSION "16"
pg_config.h:#define PG_MAJORVERSION_NUM 16
pg_config.h:#define PG_MINORVERSION_NUM 1
pg_config.h:#define PG_VERSION "16.1"
pg_config.h:#define PG_VERSION_NUM 160001
pg_config.h:#define PG_VERSION_STR "PostgreSQL 16.1 on
x86_64-pc-linux-gnu, compiled by gcc (GCC) 12.2.1 20221121 (Red Hat
12.2.1-7), 64-bit"