Re: IN clauses via setObject(Collection) [Was: Re: Prepare

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

You do understand that SQL is a standard outside of what postgresql actually
implements right?  The standard exists completely independant of pgsql.  The
people who designed JDBC designed it work using SQL style operations.  The
functionality that a PreparedStatement has is clearly designed to be that of a
PREPARE'd SQL statement.  The "efficiency" aspect of the PreparedStatement is
not specified by the JDBC interface and so the JDBC is allowed to implement the
features of a PreparedStatement without actually using a PREPARE'd statement in
SQL.  However it seems clear that the intent is that a PreparedStatement be as
close to what can be done by an SQL PREPARE'd statement.

If the SQL standard does not allow passing sets into PREPARE'd statements, that
is a technical reason why postgresql's (and basically every other database's)
PREPARE should not support "IN ?" with a set.  The people who designed the SQL
standard know way more about databases then you or I, and so I would be willing
to accept that they had a significant reason to not want to support this
behaviour.

> 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 :-)

The definition I am trying to use is the one defined by SQL.  I don't have the
exact text of the definition, however I think that I have a good sense of what
the definition is.  Besides which, defining data (in the context of SQL) to be
something that can be stored as an element of a table, sounds like a perfectly
reasonable definition to me.

> You can create *any* datatype in postgres, and create a
> column of that
> type.  You can have SET as a datatype. Moreover, you can

Sigh.  You can create a datatype with any name, but just because you call your
datatype a set does not mean you can put it where SQL set Syntax is used.

> create compound
> (row/struct) types - *none* of those is supported by JDBC currently.

Carefuly with your terminology.  The JDBC interface does support STRUCT.  If
postgresql's JDBC Driver does not support STRUCT, that is a limitation of
pgsql's JDBC Driver.

Darin