* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> writes: > > Another approach would be to have PQsetdbLogin build up a conninfo > > string and pass that into connectOptions1 instead of calling > > connectOptions1 with an empty string and then changing the values > > afterwards. That'd probably be too large of a change to get in as a > > bugfix though. An alternative might be to move the pg_fe_getauthname() > > call to connectOptions2 as it's actually a bit more work than one might > > expect and if that can be avoided then that's probably all to the good. > > Right offhand I like the idea of pushing it into connectOptions2 --- can > you experiment with that? Seems like there is no reason to call > Kerberos if the user supplies the name to connect as.
Sure thing, I'll take a look at this probably tommorow night or thursday
evening.
> > Sorry I don't have a simple answer. :/ In the end it seems like the
> > Kerberos libraries should be able to survive Kerberos not being
> > configured or whatever is going on to make it try to malloc 0-bytes...
>
> We may be spending too much time on this one point --- as long as
> Kerberos isn't *writing* into the zero-length alloc, there is nothing
> illegal immoral or fattening about malloc(0). Can you get ElectricFence
> to not abort right here but continue on to the real problem?
Good point.
Stephen
signature.asc
Description: Digital signature
