Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YGW31-0007Us-GI for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jan 2015 17:04:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YGW30-0006Lq-TY for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jan 2015 17:04:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YGW2z-0006Lj-CM for pgsql-hackers@postgresql.org; Wed, 28 Jan 2015 17:04:57 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YGW2s-0006dj-4X for pgsql-hackers@postgresql.org; Wed, 28 Jan 2015 17:04:56 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id t0SH4jvb032653; Wed, 28 Jan 2015 12:04:45 -0500 From: Tom Lane To: Stephen Frost cc: Robert Haas , Heikki Linnakangas , Magnus Hagander , PostgreSQL-development Subject: Re: PQgetssl() and alternative SSL implementations In-reply-to: <20150128165847.GY3854@tamriel.snowman.net> References: <53F1E989.8020609@vmware.com> <10419.1408475397@sss.pgh.pa.us> <53F3C87E.2080401@vmware.com> <54C8FCB0.4050304@vmware.com> <20150128165847.GY3854@tamriel.snowman.net> Comments: In-reply-to Stephen Frost message dated "Wed, 28 Jan 2015 11:58:47 -0500" Date: Wed, 28 Jan 2015 12:04:45 -0500 Message-ID: <32652.1422464685@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Stephen Frost writes: > What bothers me about this is that it punts SSL work to the application > and requires that they be coded to work with both OpenSSL and whatever > else we implement (eg: GnuTLS) to do anything but the most simple > checks. That's a problem because people are *not* going to want to > #include both OpenSSL and GnuTLS headers into their applications because > they don't know which PG will be compiled with.. Not to mention that > it'd be darn awkward to do so. The point of this is to provide an escape hatch for people who really want to do XYZ even though we provide no API for XYZ in libpq. Hopefully, those people will be few and far between, because anything that's a really common requirement should be catered for by libpq. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers