On 2020-05-30 11:29, Peter Eisentraut wrote:
My proposal would be to introduce OPENSSL_API_COMPAT=10001 into master
after the 13/14 branching, along with any other changes to make it
compile cleanly against OpenSSL 3.0.0.  Once that has survived some
scrutiny from the buildfarm and also from folks building against
LibreSSL etc., it should probably be backpatched into PG13.  In the
immediate future, I wouldn't bother about the older branches (<=PG12) at
all.  As long as they still compile, users can just disable deprecation
warnings, and we may add some patches to that effect at some point, but
it's not like OpenSSL 3.0.0 will be adopted into production builds any
time soon.

Trying to move this along, where would be a good place to define OPENSSL_API_COMPAT? The only place that's shared between frontend and backend code is c.h. The attached patch does it that way.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 0c5c83c6051688a643194388000ea356a8d055d5 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <pe...@eisentraut.org>
Date: Tue, 7 Jul 2020 19:43:22 +0200
Subject: [PATCH] Define OPENSSL_API_COMPAT

This avoids deprecation warnings from newer OpenSSL versions (3.0.0 in
particular).

Discussion: 
https://www.postgresql.org/message-id/flat/FEF81714-D479-4512-839B-C769D2605F8A%40yesql.se
---
 src/include/c.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/src/include/c.h b/src/include/c.h
index a904b49a37..03e87ae3a8 100644
--- a/src/include/c.h
+++ b/src/include/c.h
@@ -1080,6 +1080,14 @@ extern void ExceptionalCondition(const char 
*conditionName,
 #define HAVE_UNIX_SOCKETS 1
 #endif
 
+/*
+ * OpenSSL API compatibility level
+ *
+ * Set this to the minimum supported version.  This avoids deprecation
+ * warnings when building with newer OpenSSL versions.
+ */
+#define OPENSSL_API_COMPAT 10001
+
 /*
  * Invert the sign of a qsort-style comparison result, ie, exchange negative
  * and positive integer values, being careful not to get the wrong answer
-- 
2.27.0

Reply via email to