From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dominique Devienne <ddevienne@gmail.com>
cc: pgsql-general@lists.postgresql.org
Subject: Re: libpq version macro to use or not PQsocketPoll
In-reply-to: <CAFCRh-_Fz4HDKt_y+qr-Gztrh+vMiJ4EFxFHDLgC6AePJpWOzQ@mail.gmail.com>
References: <CAFCRh-_Fz4HDKt_y+qr-Gztrh+vMiJ4EFxFHDLgC6AePJpWOzQ@mail.gmail.com>
Comments: In-reply-to Dominique Devienne <ddevienne@gmail.com>
	message dated "Tue, 06 Aug 2024 15:28:21 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1340429.1722954664.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 06 Aug 2024 10:31:04 -0400
Message-ID: <1340430.1722954664@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1340430.1722954664%40sss.pgh.pa.us>
Precedence: bulk

Dominique Devienne <ddevienne@gmail.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 L=
IBPQ...

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