> Does DBI 1.38 have an API that takes an array of rows (which should be > the usual end-user interface rather than the more abstract callback > method of execute_for_fetch())? If not, it should probably be added, I > think I put in a row-wise option in my execute_array patch.
Was this ever resolved ? Was a new API i/f deemed neccesary, or was some hack on bind_param_array/execute_array considered ? Or is ArrayTupleFetch the solution to all the above ? Perhaps bind_param_array(0, [ [ tuple0 array], [ tuple1 array],...[tupleN array] ], [EMAIL PROTECTED] ) ? ie, the $p_num parameter is always zero for rowmajor binding the $bind_values parameter is an arrayref of arrayrefs, one per tuple the [EMAIL PROTECTED] is an array of \%attrs or scalar SQL TYPE codes, one per column in each tuple (or should each tuple be able to carry its own attributes info ? I'm not aware of any DBMS driver that could permit that level of control over its bulk i/f...) For those DBMSs that support SQL ARRAY parameters, the associated slot in each tuple array would itself contain any arrayref ? (Kinda gruesome, but gets the job done...) And execute_array() wo/ explicit bind_param_array() looks like execute_array( \%attrs, ( [ tuple0 array ], [ tuple1 array ],...[ tupleN array ] )) with a new attribute ArrayTupleRowMajor (or somesuch) defined ? Does the coderef supplied to ArrayTupleFetch provide a means to specify column data types ? ie, return ([EMAIL PROTECTED], [EMAIL PROTECTED]) instead of just [EMAIL PROTECTED] ? Dean Arnold Presicient Corp. www.presicient.com
