> > However, that doesn't change that some people would like us to > support > > GSSAPI, and there may be some benefit (additional applications, > better > > network authentication, etc.) for doing so. If we can get > additional > > programmers to code the support (i.e. Sun, JPL) I don't see any > reason > > not to support the *additional* authentication methods. > > Well, as I said already, a lot depends on the size of the patch. > As a reductio ad absurdum, if they drop 100K lines of code on us, > it *will* get rejected, no matter how cool it is.
Oh, absolutely. > The current Kerberos support seems to require about 50 lines in > configure.in and circa 200 lines of C code in each of the backend > and libpq. Plus a dependency on an outside library that happens to > be readily available and compatibly licensed. I would expect, without looking at the details of the API, GSSAPI to be about the same amount of code if not less. > What amount of code are we talking about adding here, and what > dependencies exactly? What portability and license hazards will be > added? The Kerberos5 libraries that we rely on today provide GSSAPI. So it would work with the same external library. Now, it could *also* work with other libraries in some cases (for example, the Win32 SSPI libraries), but with the same libraries it should work fine. //Magnus ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly