On Tue, Jul 22, 2003 at 10:27:17AM -0400, Dmitry Tkach wrote:
> >
> >
> >Here are the permutations I can remember:
> >
> >Option 1: add a method to PGStatement that explicitly sets an IN clause,
> > taking either a java.sql.Array, java.util.Collection + component type,
> > array + component type, or a custom postgresql object
> >
> > + there's no confusion as to what it means
> > + using a custom object allows access via setObject(..., Types.OTHER)
> > consistently, as well as via the extension method.
> >
> it doesn't (at least, not in the current implementation) - Types.OTHER
> ends up calling setString(), that makes it useless for IN parameters
Well, certainly, we'd need to change setObject to understand this new type.
> > - java.sql.Array and java.util.Collection have problems as PGStatement is
> > compiled for all JDKs and JDBC versions and those types may not be
> > present
> > (we could do a PGJDBC2Statement or something, but that's getting messy)
> >
> you could declare it to take Object, I suppose (that would be the only
> way anyway if you wanted to support arrays of primitive types anyway)
Good point.
> >Option 3: make setObject(n, Collection [, type]) expand to an IN clause.
> >
> > + no new methods or types needed
> > - must assume that the contents of the collection use the default type
> > mapping
> > if a type is not provided
> >
> You can require the type to be provided.
Hmm, so what does setObject with no type do in that case? Also see the next
point.
> > - if a type is provided and we apply it to the *components* of the
> > collection, this breaks the general getObject() interface of "bind this
> > object interpreting it as this particular type".
-O
