Re: Prepared Statements

The problem with this (and other similar suggestions in this thread -
like use PGArray etc.) is that the app will not even compile with
postgres jdbc classes.
The whole point in using jdbc interfaces is to abstract the application
from the particular driver implementation.

The way it works currently, it is entirely possible either (text
representation of arrays vary between vendors, as do ways you can use to
specify sets as parameters), but, at least,  you don't have to maintain
the whole special piece of code, that can only compile when postgres
driver is available.

Dima

Oliver Jowett wrote:

>On Fri, Jul 18, 2003 at 02:22:24PM -0400, Dmitry Tkach wrote:
>
>
>
>>What I am concerned about is the "in" thing -
>>
>>select * from sometable where x in ?;
>>setObject (1, "(1,2,3,4,5)");
>>
>>that works just fine right now, and will be irreperably broken by this
>>patch...
>>
>>
>
>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
>
>