Here's a thought; do you think it's feasible to detect cases where the
protocol=3 driver throws an error due to invalid or ambiguous typing
issues when the protocol=2 driver would just do the expected thing?
Instead of throwing the error back to the user, could the driver then
issue a 'describe statement' call, use the result to disambiguate the
parameter settings, and re-issue the call? It increases the overhead
but only for the error cases, and the result could be cached to avoid
repeating that overhead.
I haven't done any hacking in the driver yet, so maybe it would be too
much of a pain to implement to justify any possible gains.
-- Mark Lewis
On Mon, 2005-11-21 at 18:08 -0500, Kris Jurka wrote:
>
> On Mon, 21 Nov 2005, Tjioe Ai Xin wrote:
>
> >
> > My code is like this: I have query: "Select count(*) / paramPage from
> > tblFirst where condition"; The paramPage were filled from parameter
> > which I specified as string data type. So I using setString method for
> > my prepared statement for passing paramPage value. When I'm using the
> > old jdbc driver pg74jdbc3.jar, I got no problem at all. But when I try
> > to upgrade my PostgreSQL to 8.0.3. I got problem data type error.
> >
> > Can PostgreSQL do data type automated casting in prepared statement again?
> > So I do not need change my code :)
> >
>
> Yes, and no. You can restore the old behavior by adding
> ?protocolVersion=2 to your connection URL, but using the older protocol
> also means some new features and performance gains will be unavailable to
> you.
>
> Kris Jurka
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend