At this point I think I need to re-ask my original question. Is the ability to
pass a set throught a ? in a JDBC PreparedStatement something that should be
do-able at all, regardless of if you can find an inoffensive way through the
JDBC interface?
I believe that a JBDC PreparedStatement is meant to be just a front end for an
SQL PREPARE statement. If it is not valid to send a set in an SQL PREPARE
statement (which I have not yet been given a definative answer for) should there
be away to pass it through a JDBC PreparedStatement? What happens when you want
JDBC PreparedStatements to be PREPARE'd statements? Will this ability be
dropped at that time or will some messy hack be defined to continue to support
this behaviour?
BTW, Dima, I would define "data" as it is defined by SQL, unfortunately I don't
know that exact definition. However it looks like something is data if a column
can be created to store it. So I would say that an array is a data element, a
set is a Syntax element that contains data.
Darin
> > > I think Dima is arguing that Collection could be treated
> as an special case
> > > where it indicates a list of something instead of a
> single something.
> > >
> > > So, we would iterate through this Collection using its
> iterator and, for
> > > each Object obtained, act like a setObject has been used
> with that Object
> > > and the JAVA TYPE as an argument.
> > >
> > > The Types.OTHER is used for database specific SQL types
> or for Dynamic Data
> > > Access support. As the Collection class is not a data
> type there is no
> > > chance of confusion.
> >
> > Ya, I understand. My main objection is that setObject(n, object,
> > Types.INTEGER), in all other cases, means "interpret object
> as an integer,
> > or fail if it can't be cast in that way".
>
> Also.. what would we do with this object?
>
> public class AnnoyingObject implements java.util.Collection,
> java.sql.Array {
> // ...
> }
>
> then setObject(n, new AnnoyingObject(), Types.ARRAY);
>
> Is that an Array, or an IN clause of Arrays? :)
>
> (Array is the obvious candidate for also being a Collection,
> but potentially
> you could do it with other types too)
>
> -O
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index
> scan if your
> joining column's datatypes do not match
>
