Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS

On Wed, Mar 14, 2012 at 02:00:19PM +0000, Martin J. Evans wrote:
> >
> >>There are cases where an imp_sth is passed as a parameter yet
> >>D_imp_xxh(sth) is being called. So you end up with imp_sth and imp_xxh
> >>pointers that point to the same thing. See dbd_st_fetch and dbd_bind_ph for
> >>example. Just delete the D_imp_xxh(sth); line and change all imp_xxh in
> >>the function to be imp_sth instead. There may be cases where the same
> >>applies with imp_dbh.
> >
> >Yeah, thanks, I'll fix those.
> 
> Those D_imp_xxh calls in dbd_st_fetch and dbd_bind_ph are simply there
> because those fns call DBIh_SET_ERR_CHAR and that takes an imp_xxh_t.
> I have removed them but then I need to cast imp_dbh/imp_sth to
> imp_xxh_t before calling DBIh_SET_ERR_CHAR so that then makes we
> wonder why imp_xxh_t is really required? just so you can pass an
> imp_dbh_t or an imp_sth_t to it?
>
> The only places DBD::ODBC using imp_xxh_t is in calls to
> DBIh_SET_ERR_CHAR and DBIc_TRACE (and a few calls to DBIc_TYPE). So
> are you effectively saying imp_xxh_t exists for the simple reason it
> could be either an imp_sth_t/imp_dbh_t and if that is so I presume I
> can just delete all D_imp_xxh macros where the imp_xxh is passed to
> DBIh_SET_ERR_CHAR/DBIc_TRACE, pass the real imp_*h and cast it and
> avoid a call to dbih_getcom2?

Yes. imp_xxh_t gives access to those struct elements that are common
to all handles. It's always safe to cast a imp_??h_t to imp_xxh_t.

Tim.