I have to agree that it would be better to provide a solution
using API calls than a solutions that requires one to send SQL syntax
into a ?.
But why can't we kill both birds with an implementation of
java.sql.Array? If you need to use an Array, you can use a PGArray that
wraps an Object[]. If you want to do an in clause, do "where foo in (?)"
or "where foo in ?" and then use ps.setArray() instead of setObject().
Then we can make the docs explicit on this.
It does look like java.sql.Array is kind of overkill here, but we
can provide simple constructor that makes the common usage patterns easy,
and if you can't get a full ResultSet from your in clause in v1.0, so be
it.
Aaron
On Sat, 19 Jul 2003, Oliver Jowett wrote:
> How about:
>
> + create an org.postgresql.InSet class that wraps an Object[] array and java.sql.Types value
> + use setObject(N, new InSet(myArray, Types.INTEGER));
>
> The Javadoc for PreparedStatement.setObject() says:
>
> Note that this method may be used to pass datatabase- specific abstract data
> types, by using a driver-specific Java type.
>
> so presumably this is the right way to do it. setObject() would handle an
> InSet by individually escaping the components of the array it wraps as if
> they had been passed to setObject() and turning them into an IN-like clause.
>
> For arrays we just need to fix setArray() so that it does the same sort of
> thing as described above, using the java.sql.Array methods to get the
> component objects. And maybe provide a simple implementation of Array that
> wraps a Java array (users can always provide their own, anyway).
>
> Any thoughts? I can try to sort out patches, but I'm a bit short on time
> right now so no promises.
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
