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


Reply via email to