On Fri, Sep 22, 2006 at 05:40:53PM -0700, Dean Arnold wrote: > > > >I think I'm going to take the view that all drivers should support > >'?' style placeholders and that those should be used for execute_array > >and execute_for_fetch. > > > >For database that don't support '?' style placeholders it's pretty > >trivial for the driver to rewrite them as 'p1', 'p2' etc etc. > >That's exactly what DBD::Oracle as always done. > > Just so I'm clear: > > "DBI's default execute_array()/execute_for_fetch() requires the use of > positional (i.e., '?') placeholders. Drivers which B<require> named > placeholders must implement their own execute_array()/execute_for_fetch() > methods to properly sequence bound parameter arrays."
"... or they can emulate positional placeholders (DBD::Oracle does this)". I'd guess that emulating positional placeholders would be both simpler and more useful for general script portability. > >Could you update the docs? (If you don't have write access to the dbi > >repository yet, send me your auth.perl.org username and I'll give it to > >you.) > > OK, after I finish up my release to shake out anything else. I've got a few > other items I'd like to note in the DBI::DBD pod wrt > ParamValues/ParamArrays... > actually, I'm going to try and a create a detailed list of attributes > that do or don't get forwarded to a driver's STORE/FETCH > methods...ParamValues/ > ParamArrays gave me fits until I figured out DBI didn't route them thru > my FETCH(). That is a very fuzzy area of the DBI internals. I might accept a change to make all (non-speed-critical) attribute access go via STORE/FETCH. > Plus the strangeness of _new_sth() wrt which attributes it will > save and which it won't. Another fuzzy area. Perhaps getting the current behaviour documented would be a first step towards changing the behaviour to be more useful... Tim.
