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