On Sat, Jul 23, 2005 at 10:13:05AM -0700, Dean Arnold wrote: > > Precisely. At present, the client stubs accumulate the bind > operations, and then pass an indication of the binding (including > the optional type info) over to the apt. thread on fetch(), > where the bindings are detected, and the apt. thread applies > a local bind (solely in order to emulate fetchall_XXX() > behavior wrt bind()), and then returns the resulting bound values > to the client stub. If it weren't for the fetchall_XXX > case, the client stub could just dump the row values into > the bound variables. > > The more I think about this, the more I'm convinced > I should just POD a caveat that fetchall_XXX with bind_col() > isn't supported (much like binding multiple variables to a single > column). Why would anyone want to do that anyway?
I very much doubt anyone depends on the interaction of bind_col() with fetchall_XXX(). I'm not even sure what that interaction is. I'd guess the bound variable is left with the value from the last row fetched. It's certainly not documented. I'd be happy to consider a patch that documents that it's undefined. Probably belongs in finish() as fetching beyond the last row is defined to implicitly/effectively call finish. Tim.
