From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Dima Tkach <dmitry(at)openratings(dot)com> |
Cc: | Kim Ho <kho(at)redhat(dot)com>, Fernando Nasser <fnasser(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: Prepared Statements |
Date: | 2003-07-21 00:02:41 |
Message-ID: | 20030721000241.GB665@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Sun, Jul 20, 2003 at 12:39:45PM -0400, Dima Tkach wrote:
> The problem with this (and other similar suggestions in this thread -
> like use PGArray etc.) is that the app will not even compile with
> postgres jdbc classes.
> The whole point in using jdbc interfaces is to abstract the application
> from the particular driver implementation.
My current approach is what Fernando suggested -- use setArray() and look
for a preceeding IN. This can work without needing any postgres specific
classes -- I'll add a simple implementation of java.sql.Array that wraps a
Java array to the driver source, but if you don't want to be dependent on
the driver you can provide your own implementation.
The interface-abstraction argument only really works up to the point where
you want to do something not defined in the interface. Usually when I'm
doing DB-specific extension stuff I have a per-DB subclass that does the
special bits; if you don't have the driver available, you don't compile that
subclass. So I don't really buy the "can't build" argument. The same
thing applies to extensions like setUseServerPrepare(), BTW.
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2003-07-21 00:15:28 | Re: getArray() fails to handle some string array cases |
Previous Message | Kris Jurka | 2003-07-20 22:55:51 | Re: jdbc batch performance problem |