Re: IN clauses via setObject(Collection) [Was: Re: Prepare - Mailing list pgsql-jdbc

Darin Ohashi wrote:

>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?
>

There is no technical reason why sql prepare cannot support "IN ?"
If it is not supported by the backend at the moment should not affect
the general decision of whether or not having such a feature is useful
to have in the jdbc driver or not.

For example, in 7.2 there is no SQL PREPARE *at all*.
Following your logic, should we conclude that PreparedStatement should
not then be implemented  in 7.2 jdbc?

> 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?
>
If the backend doesn't support this case, it will have to be an
exception... until the support is added to the backend (which, I am
sure, will happen eventually).


>
>BTW, Dima, I would define "data" as it is defined by SQL, unfortunately I don't
>know that exact definition.
>
Nice :-)
Are you saying that you are using this term without knowing what it
means (even to you)??? :-)

>  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.
>
Ok. Then, I guess, we should conclude that using "IN ?" should not be
supported *IF* your definition of "data" is accepted.
I don't see any reason why it should (be accepted) though :-)

It seems to serve no other purpose then to exclude "IN ?" functionality ...

 From the theoretical standpoint, the *only* difference between an array
and a set is that the former can contain duplicates, and the latter
cannot...
I don't see any sane reason whatsoever to declare one being "data", and
the other one being "syntax".
While, like you I am not sure what "data" means (and would much prefer
to avoid using that term at all therefore), I am pretty sure that an
array, and a set should be *simultaneously* considered "data" or "not data".

Defining data as something you can create a column for doesn't seem to
make any sense to me, as I said above.
And, moreover, it actually creates more problems to your point than it
solves.

You can create *any* datatype in postgres, and create a column of that
type.  You can have SET as a datatype. Moreover, you can create compound
(row/struct) types - *none* of those is supported by JDBC currently.

Dima