On Mar 7, 2010, at 3:27 PM, Tim Bunce wrote: > Uh, yeah, I just looked at the code. Sometimes I confuse myself. > I think that's a bug. I always intended connected() to be used as an > on-new-physical-connection-established hook. > > Any objections to making it so?
Not from me, but you might get some bug reports. > Looking at the code I can see an issue with clone(): it'll clone using > the same method (connect/connect_cached) as the handle that's being > cloned. I guess I can document that as a feature :) Never even noticed clone() before. But yeah, that sounds like a decent feature, as long as connect_cached does not return the exact same handle, eh? That is, clone() should always create a second, separate handle. > Yes, the additional hook for sql_type_cast_svpv. But I shouldn't have > bumped DBISTATE_VERSION for just that - the change was binary compatible > with old drivers. (Drivers that care can use the DBIXS_REVISION macro > to check if sql_type_cast_svpv is available at compile time and check > it's non-zero to check it's available at runtime.) Dunno what sql_type_cast_svpv is for, but glad it's not just me. > Fixed in r13837. Thanks. So there might be some folks around with the dev release who will have v95, even though the final will be v94? Best, David