From: | Darin Ohashi <DOhashi(at)maplesoft(dot)com> |
---|---|
To: | "'Dmitry Tkach'" <dmitry(at)openratings(dot)com>, Darin Ohashi <DOhashi(at)maplesoft(dot)com> |
Cc: | "'Oliver Jowett'" <oliver(at)opencloud(dot)com>, Fernando Nasser <fnasser(at)redhat(dot)com>, Kim Ho <kho(at)redhat(dot)com>, Barry Lind <blind(at)xythos(dot)com>, pgsql-jdbc-list <pgsql-jdbc(at)postgresql(dot)org>, Dave Cramer <Dave(at)micro-automation(dot)net> |
Subject: | Re: IN clauses via setObject(Collection) [Was: Re: Prepare |
Date: | 2003-07-21 18:51:09 |
Message-ID: | F17255C2B596D3119A5600508B44FA68052EB873@courier.maplesoft.on.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Tkach | 2003-07-21 18:53:06 | Re: Detecting 'socket errors' - closing the Connection object |
Previous Message | David Wall | 2003-07-21 18:41:05 | Re: Detecting 'socket errors' - closing the Connection object |