Oliver Jowett wrote:
>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.
>
>
I don't want to provide my own iplementation either :-)
I was fairly happy with what it used to be - just call setObject () and
be done with it
Anything else does look like an overkill...
>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.
>
Yep. That's exactly why I was arguing against having it to beging with
back in the beginning of 7.3
.. I lost that one too :-(
... but still believe it was the wrong idea.
I mean, as I said before, I do have do go an extra mile because of this
precompiled query plan stuff...
I am writing functions in C that cache query plans and return strings,
and call them from java, and pase strings back in rows... I just can't
afford casting my statements to org.jdbc.postgres.Something... sorry - I
can't write my apps assuming that postgres is the only db they'll ever
need :-(
Dima