Re: PQgetssl() and alternative SSL implementations
От | Stephen Frost |
---|---|
Тема | Re: PQgetssl() and alternative SSL implementations |
Дата | |
Msg-id | 20140819150507.GB16422@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: PQgetssl() and alternative SSL implementations (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: PQgetssl() and alternative SSL implementations
Re: PQgetssl() and alternative SSL implementations |
Список | pgsql-hackers |
* 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. What I was wondering is which one we should be modeling off of. One thought I had was to look at what Apache's mod_ssl provides, which can be seen here: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html I know that I've used quite a few of those. Telling users they simply can't have this information isn't acceptable. I'm not a huge fan of just passing back all of the certificates and making the user extract out the information themselves, but if it comes down to it then that's at least better than removing any ability to get at that information. > 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. Thanks, Stephen
В списке pgsql-hackers по дате отправления: