Stephen Frost wrote:

Also, do we really want to import the NSPR into Postgres? I suspect not. Of course, the only thing that people are tripping over license-wise is libpq. But I think we would want to keep that as lean and mean as possible, too.

erm, I'm not really sure what you're saying here but perhaps I can
clarify:  I wasn't suggesting to add any serious amount of source code
to PostgreSQL - NSS would be used just as OpenSSL is today, and as GNUTLS support was proposed, a seperate library which is distributed independently of PostgreSQL but can be compiled against. I don't know

I suspect that Andrew was concerned about the dependency NSS has on NSPR.
NSS dates back to the days before universal support for threads and mutexes.
NSPR was (is) a library designed to abstract platform differences in those areas, and to provide its own implementations where none was available in the OS (e.g. old MacOS, 16-bit Windows). So for example if you want to open an SSL connection using NSS you get to hand it an NSPR socket handle, not an OS socket (however, there are functions that allow construction of one from the other). For an application that has otherwise no need for cross-platform service abstraction, or that has already
solved the problems NSPR solves in a different way, NSPR looks
like a big ball of goo that you don't need. NSS can't exist in an application without NSPR.

Having said that, except in the case of cooperative threading environments (do those exist today??), there's no requirement on the application to actually use NSPR for
anything other than plumbing underneath NSS.

Applications that want to handle their own I/O underneath the SSL library
(particularly useful in servers) will often not be happy with NSS due to its
layering above NSPR I/O.

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to