* Magnus Hagander ([EMAIL PROTECTED]) wrote: > Stephen Frost wrote: > > If both are made available then I think that'd work fine for us. I'm > > concerned that the windows builds wouldn't include a version of libpq w/ > > GSSAPI... > > The default build wouldn't. The binary build wouldn't. If you by GSSAPI > mean MIT linking - SSPI does GSSAPI *authentication* just fine.
I don't think SSPI supports having seperate credential caches, a different default realm, etc... (and I'm not sure how you'd set them up even if it did). > One reason is that bringing in and configuring the MIT libraries is a > significant overhead. Erm, isn't this what's done now? Are we actually overloaded in some way on the buildds? Would this actually be a measurable reduction in the overhead of the buildds? I find this argument less than convincing reasoning for dropping existing functionality... > Nothing would prevent you from building your own DLL with Kerberos linking. Except when it breaks because it's not being tested in the build system... :/ I expect there are other such things in the same situation but I'm rather unhappy that it's something which is actually going to impact people (at the least me) as opposed to GNU readline on some esoteric architecture. > > If I was confident that we could easily build it ourselves > > then I wouldn't care as much but, since I've never had to build libpq on > > Windows before, I'm not sure what effort is involved or what tools are > > required. I'm also not thrilled by the prospect. :) > > It's not hard, at least if you use MSVC to build it. It's harder with > MingW, but far from impossible. MSVC would be a rather unhappy requirement. Do we have buildds running with MingW? Settings up buildds is documented, etc, no? I don't know if I could dedicate a machine to it but at least if I can build my own buildd setup using the scripts and whatnot it might not be too bad.. > > I have to admit that this does kind of make > > me wish a bit for a 'libpq config file' even though I'm generally against > > such things. Having the same easy switch as we do w/ Mozilla would be > > really nice. > > So what we'd need in that case is a new libpq connectionstring > parameter. Which can be done, but it'd require that all frontends that > use libpq add support for it - such as pgadmin. I'm not sure if the ODBC > driver will support arbitrary arguments, otherwise that one needs it too. If the ODBC driver doesn't support changes to the connectionstring (and I think it does, actually), that'd probably be a sensible thing to add anyway. Having to have what's essentially a library-config option handled by all the clients does kind of suck though. > As I'm sure you can tell, I'm far from convinced this is a good idea ;-) It's also not exactly unheard of. I'm pretty sure what mozilla does is basically just dlopen() the appropriate library. I'm not sure if it's even got an internal set of dlls which link to the sspi/gssapi dlls explicitly. If it does we might be able to swipe it. Sorry for my lack of familiarity, but does SSPI provide a GSSAPI identical to the MIT one? For some reason I was thinking it did (hence why the dll magic just works, but there could be more going on in those possibly) in which case I'm not even sure you'd need the MIT stuff available to compile with support for it? > Anybody else want to comment on this? I've always been rather unhappy at the apparent lack of user participation on this list. :/ I don't mean to imply that I speak for the silent majority, just that it's frustrating when trying to gauge the impact of changes. Thanks, Stephen
Description: Digital signature