Re: libpq version macro to use or not PQsocketPoll

On Tue, Aug 6, 2024 at 4:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dominique Devienne <ddevienne(at)gmail(dot)com> writes:
> > 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...
>
> 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.

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

> > 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.

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)
> and not very readable.

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
> of libpq-fe.h.

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