Re: Setting min/max TLS protocol in clientside libpq - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Setting min/max TLS protocol in clientside libpq
Date
Msg-id C77180DF-0CF3-4DB3-8799-41F0D4A1E14B@yesql.se
Whole thread Raw
In response to Re: Setting min/max TLS protocol in clientside libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Setting min/max TLS protocol in clientside libpq
List pgsql-hackers
> On 14 Jan 2020, at 15:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>>>> On 11 Jan 2020, at 03:49, Michael Paquier <michael@paquier.xyz> wrote:
>>>> One thing I noticed when looking at it is that we now have sha2_openssl.c and
>>>> openssl_protocol.c in src/common.  For easier visual grouping of OpenSSL
>>>> functionality, it makes sense to me to rename sha2_openssl.c to openssl_sha2.c,
>>>> but that might just be pointless churn.
>
>>> Databases like consistency, and so do I, so no issues from me to do a
>>> rename of the sha2.c file.  That makes sense with the addition of the
>>> new file.
>
>> Done in the attached v3.
>
> I'm kind of down on renaming files unless there is a *really* strong
> reason for it.  It makes back-patching more difficult and it makes
> it much harder to follow the git history.  And, seeing that there is
> also a src/common/sha2.c, it seems to me that renaming sha2_openssl.c
> will just break consistency in a different way.
>
> Maybe the problem is you've got the new file's name backwards.
> Maybe it should be protocol_openssl.c.

Thats a very good argument, I’ll send a v4 with protocol_openssl.c when back at the computer.

cheers ./daniel


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unicode escapes with any backend encoding
Next
From: Nikita Glukhov
Date:
Subject: Re: SQL/JSON: JSON_TABLE