Thread: libpq version macro to use or not PQsocketPoll
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
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 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
On Tue, Aug 6, 2024 at 4:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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 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
On Tue, Aug 6, 2024 at 4:48 PM Dominique Devienne <ddevienne@gmail.com> wrote: > On Tue, Aug 6, 2024 at 4:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Dominique Devienne <ddevienne@gmail.com> writes: > > 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. Hi. Doesn't look like beta3 _has_ them (pun indented :)). Was probably too late for the beta3 release train. > We can have both. Also, version macros don't > 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"