Re: Prepared Statements - Mailing list pgsql-jdbc

See my comments below.

On Mon, 2003-07-21 at 16:24, Dmitry Tkach wrote:
> >
> >
> >Um, so you don't want to depend on the JDBC postgresql driver at all, but
> >don't mind having postgresql-specific behaviour elsewhere so long
> >as you can do it purely through the JDBC interface? That seems a bit
> >inconsistent.
> >
> >
> I don't see anything "inconsistent" about it.

But please... did you ever use a different database than Postgres ? The
way you're passing the parameters is VERY much postgres specific,
furthermore, it relies on some non-standard behavior...

> I am just choosing the lesser of two evils.
> At least, I don't need to know what database I am going to be working
> with when I compile the code.

... which problem you wouldn't have if you would use standard JDBC code.
I agree that standards suck sometime, but then if you want to use a DB
specific feature, I can't see why not make it a compile time necessity -
it might be a further benefit to remind you that your code will not work
with other databases.

>
> >Note that using setObject() to set IN clauses is no less postgresql-specific
> >than using setArray() would be .. I know of at least one DB where you really
> >can only set data values in a prepared statement as the prepared SQL is
> >compiled down to a form of bytecode for DB-side execution, there *is* no
> >textual substitution that goes on.
> >
> Right. I do need a scheme like what you suggest below to set up
> database-specific logic.
> The difference is - I do not need all the possible jdbc drivers to be
> installed just to compile my application.
> And I do not need to know which driver a particular customer is using to
> send him my application.
> And I don't need to force my customers to have to request a new app from
> me if they decide to switch to another database.

But yes you force your customers to use Postgres, or maybe to a set of
databases which accept this hack - it is not standard.

>
> With your suggestion, the only way I can have the above is to pack all
> the possible jdbc drivers into every  build of the app...

Yes, all the drivers which you are using special features from. That
makes perfect sense - those are vendor specific dependencies in your
code, the library will remind you about it all the time so you don't
forget to tell the customers about it ;-)

Cheers,
Csaba.