From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
cc: Jeff Davis <pgsql@j-davis.com>, Andrew Dunstan <andrew@dunslane.net>,
        Andres Freund <andres@anarazel.de>,
        Postgres hackers <pgsql-hackers@lists.postgresql.org>,
        Michael Paquier <michael@paquier.xyz>,
        Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
        Stephen Frost <sfrost@snowman.net>,
        Thomas Munro <thomas.munro@gmail.com>
Subject: Re: Support for NSS as a libpq TLS backend
In-reply-to: <9B16F5EA-5F01-4E9D-BDD7-8E0D2166D6F5@yesql.se>
References: 
 <CAA8=A7-suZg90M7Fgyo1Rfymkrpdh_Z547RKXrbHirsAmojQSw@mail.gmail.com>
 <20200904012334.GF19499@paquier.xyz> <20200917074134.GX2873@paquier.xyz>
 <BAD11CCA-E712-4906-8A27-94C2AA0E696E@yesql.se>
 <20200929055939.GF7117@paquier.xyz>
 <DE377D9A-BFFC-492C-A2B8-2AE6EBBBE740@yesql.se>
 <411593A7-E037-474D-BFD7-D3D6683C1D46@yesql.se>
 <B1ADEE76-3E33-4E9D-B830-3AA89B1C42D2@yesql.se>
 <20201020191529.5yverw3ybaube3pg@alap3.anarazel.de>
 <907FA7D1-9BD9-464B-A6EC-DEEB53438D36@yesql.se>
 <20201028063957.cvln377jgao33ssu@alap3.anarazel.de>
 <1538bd8894fc723d97d5c41b9d4bb8feb9db0d43.camel@j-davis.com>
 <D187206C-B942-484B-AB39-5AD25191D6AB@yesql.se>
 <8228d950-5bee-d1e9-b0ad-577a854939fa@dunslane.net>
 <aa16d04bf822b16e593a2de09766fa256526946f.camel@j-davis.com>
 <9B16F5EA-5F01-4E9D-BDD7-8E0D2166D6F5@yesql.se>
Comments: In-reply-to Daniel Gustafsson <daniel@yesql.se>
	message dated "Thu, 03 Jun 2021 22:49:02 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <93658.1622753745.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 03 Jun 2021 16:55:45 -0400
Message-ID: <93659.1622753745@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/93659.1622753745%40sss.pgh.pa.us>
Precedence: bulk

Daniel Gustafsson <daniel@yesql.se> writes:
> It might also put us a hard spot if the next TLS spec ends up being call=
ed
> something other than TLS?  It's clearly happened before =3D)

Good point.  I'm inclined to just stick with the SSL terminology.

>> Also, do we have precedent for GUC aliases? That might be a little
>> weird.

> I don't think we do currently, but I have a feeling the topic has surfac=
ed here
> before.

We do, look for "sort_mem" in guc.c.  So it's not like it'd be
inconvenient to implement.  But I think user confusion and the
potential for the new terminology to fail to be any more
future-proof are good reasons to just leave the names alone.

			regards, tom lane