From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: OpenSSL 3.0.0 compatibility |
Date: | 2020-07-08 16:03:48 |
Message-ID: | c07ce8fc-6c11-dfac-06ef-684d43a3d807@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-07-08 16:51, Robert Haas wrote:
> On Tue, Jul 7, 2020 at 1:46 PM Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> 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.
>
> So, if we go this way, does that mean that we're not going to pursue
> removing dependencies on the deprecated interfaces? I wonder if we
> really ought to be doing that too, with preprocessor conditionals.
> Otherwise, aren't we putting ourselves in an uncomfortable situation
> when the deprecated stuff eventually goes away upstream?
I don't think there is a rush. The 3.0.0 alphas still support
interfaces deprecated in 0.9.8 (released 2005). AFAICT, nothing tagged
under this API compatibility scheme has ever been removed. If they
started doing so, they would presumably do it step by step at the tail
end, which would still give us several steps before it catches up with us.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2020-07-08 16:16:25 | Re: TAP tests and symlinks on Windows |
Previous Message | Fujii Masao | 2020-07-08 15:37:57 | Re: max_slot_wal_keep_size and wal_keep_segments |