On 2014-08-19 11:05:07 -0400, Stephen Frost wrote: > * Andres Freund (and...@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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers