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
