patch: support user implementations of Array in setArray()

This patch modifies setArray() to handle implementations of Array other than
the driver's own (which you can only get from getArray(), anyway, making
setArray() not very useful currently).

The "right way" of implementing this requires a lot of restructuring of the
setXXX code, so I've taken the easy way out and implemented it by calling
setObject() for each element and stealing the resulting m_bind[] value. This
requires some extra escaping of string literals so we can easily turn a
string literal into an array value by replacing the enclosing '' with "".

This version also uses reflection to get at the array elements regardless of
the type of the array (Object[] vs primitive-type[]). It's easy enough to
expand this out to explicitly deal with the different array types and avoid
reflection, if there's interest. I haven't benchmarked the two approaches --
reflection's got a lot faster recently so I suspect there's not much between
them.

Also attached is a testcase for getArray() and setArray(). The tests that
use server-side prepare will fail without my earlier patch that corrects the
types generated by setObject().

Should we provide a simple implementation of Array with the driver? e.g.
something like the WrappedArray used in the testcase.

-O

On Wed, Jul 23, 2003 at 02:17:09AM +1200, Oliver Jowett wrote:
> This patch modifies setArray() to handle implementations of Array other than
> the driver's own (which you can only get from getArray(), anyway, making
> setArray() not very useful currently).

I've just realized that this is unlikely to support multidimensional arrays
as it stands. Then again, the current getArray() implementation doesn't
support them either.

-O