From: Andres Freund <andres@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: PQgetssl() and alternative SSL implementations
Date: Tue, 19 Aug 2014 17:26:13 +0200
Message-ID: <20140819152613.GC30525@awork2.anarazel.de> (raw)
In-Reply-To: <20140819150507.GB16422@tamriel.snowman.net>
References: <53F1E989.8020609@vmware.com>
<20140819144841.GA16422@tamriel.snowman.net>
<20140819145547.GB30525@awork2.anarazel.de>
<20140819150507.GB16422@tamriel.snowman.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2014-08-19 11:05:07 -0400, Stephen Frost wrote:
> * Andres Freund (andres@2ndquadrant.com) wrote:
> > On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:
> > > At first blush, I'd say a whole bunch.. Off the top of my head I can
> > > think of:
>
> [...]
>
> > I'm not really sure we need all that. We're not building a general ssl
> > library abstraction here.
>
> Really? I'm pretty sure that's exactly what we're doing.
No. We should build something that's suitable for postgres, not
something general. We'll fail otherwise. For anything fancy the user has
to look at the certificate themselves. We should make it easy to get at
the whole certificate chain in a consistent manner.
> Telling users they simply can't have this information isn't
> acceptable.
Meh. Why? Most of that isn't something a normal libpq user is going to
need.
> > What I'm wondering is whether we should differentiate 'standard'
> > attributes that we require from ones that a library can supply
> > optionally. If we don't we'll have difficulty enlarging the 'standard'
> > set over time.
>
> If we end up not being able to provide everything for all of the
> libraries we support then perhaps we can document which are available
> from all of them, but I'd hope the list of "only in X" is pretty small.
I'm pretty sure that we can't build a reasonable list of the information
exposed by any library. Especially as we're likely going to need some
mapping to agree to map to the common names.
I'd just go for plain names for standard attributes and X-$library- for library
specific stuff.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@2ndquadrant.com, sfrost@snowman.net, hlinnakangas@vmware.com
Subject: Re: PQgetssl() and alternative SSL implementations
In-Reply-To: <20140819152613.GC30525@awork2.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox