From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, cary huang <hcary328(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Setting min/max TLS protocol in clientside libpq |
Date: | 2020-01-14 14:49:27 |
Message-ID: | 6267.1579013367@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 11 Jan 2020, at 03:49, Michael Paquier <michael(at)paquier(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Verite | 2020-01-14 14:53:37 | Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR |
Previous Message | Georgios Kokolatos | 2020-01-14 14:44:51 | Re: Duplicate Workers entries in some EXPLAIN plans |