Back in commit 6991e774e we established a policy that, well,
I'll just quote the commit message:

    Provide feature-test macros for libpq features added in v14.
    
    We had a request to provide a way to test at compile time for the
    availability of the new pipeline features.  More generally, it
    seems like a good idea to provide a way to test via #ifdef for
    all new libpq API features.  People have been using the version
    from pg_config.h for that; but that's more likely to represent the
    server version than the libpq version, in the increasingly-common
    scenario where they're different.  It's safer if libpq-fe.h itself
    is the source of truth about what features it offers.
    
    Hence, establish a policy that starting in v14 we'll add a suitable
    feature-is-present macro to libpq-fe.h when we add new API there.
    (There doesn't seem to be much point in applying this policy
    retroactively, but it's not too late for v14.)

libpq has grown a bunch of new features in v17, and not one of
them adhered to this policy.  That was complained of at [1],
so I looked into fixing it.  After diff'ing v16 and v17 libpq-fe.h,
it looks like we need roughly this set of new feature-test macros:

LIBPQ_HAS_ASYNC_CANCEL          PGcancelConn typedef and associated routines
LIBPQ_HAS_CHANGE_PASSWORD       PQchangePassword
LIBPQ_HAS_CHUNK_MODE            PQsetChunkedRowsMode, PGRES_TUPLES_CHUNK
LIBPQ_HAS_CLOSE_PREPARED        PQclosePrepared, PQclosePortal, etc
LIBPQ_HAS_SEND_PIPELINE_SYNC    PQsendPipelineSync
LIBPQ_HAS_SOCKET_POLL           PQsocketPoll, PQgetCurrentTimeUSec

(Feel free to bikeshed on the names, but I think we don't want 'em
to get too much longer than these.)

Alternatively we could decide that people can use configure probes
to see if these functions are there, but I still think that there's
a good rationale for the feature-test-macro approach.  It saves
people from re-inventing that wheel, it standardizes the way to
check these things (in particular, discouraging people from abusing
the server version number for this), and it provides some handy
documentation about what's new or not so new.

In connection with that last point, I wonder if we should include
commentary about when things came in.  I'd originally thought of
just inserting the above names in alphabetical order, but now I
wonder if the patch ought to look more like

  */
+/* Features added in PostgreSQL v14: */
 /* Indicates presence of PQenterPipelineMode and friends */
 #define LIBPQ_HAS_PIPELINING 1
 /* Indicates presence of PQsetTraceFlags; also new PQtrace output format */
 #define LIBPQ_HAS_TRACE_FLAGS 1
+/* Features added in PostgreSQL v15: */
 /* Indicates that PQsslAttribute(NULL, "library") is useful */
 #define LIBPQ_HAS_SSL_LIBRARY_DETECTION 1
+/* Features added in PostgreSQL v17: */
+ ... as above ...

Thoughts?

                        regards, tom lane

[1] 
https://www.postgresql.org/message-id/flat/CAFCRh-_Fz4HDKt_y%2Bqr-Gztrh%2BvMiJ4EFxFHDLgC6AePJpWOzQ%40mail.gmail.com


Reply via email to