Re: prepared statement incompatibility

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Byron Nikolaidis <ByronN(at)routescape(dot)com>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: prepared statement incompatibility
Date: 2005-06-28 22:29:12
Message-ID: 42C1CF38.9010603@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Byron Nikolaidis wrote:

> But with the previous driver, we were actually using protocol version 3,
> so it doesn’t appear that the driver strictness is actually directly
> related to protocol version 3. I’m curious as to what is it that
> actually changed in the 8.x drivers and why?

It *is* related to use of protocol version 3. However the 7.4-era
drivers used the simple query protocol which doesn't let you
parameterize queries, and did parameter substitution on the driver side
-- this was basically a dumb translation of the v2 code.

The 8.0-era drivers use the v3 extended query protocol to parameterize
queries and bind parameters, even when the resulting statement is not
preserved (i.e. prepareThreshold has not been reached). This requires
supplying types for each parameter, and the driver believes what you
tell it at the JDBC layer. You then get into trouble with the backend's
strict typing rules.

See http://www.postgresql.org/docs/8.0/static/protocol.html for protocol
docs -- compare "simple query" vs "extended query".

> Would it be possible to add a connection property to control just this
> strict type behavior, something like “strictTypes=false” ?

Not easily, see the archives for previous discussion. Passing "unknown
type" for a String parameter doesn't always work and has the potential
to hide real errors.

-O

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message sarves 2005-06-29 07:39:02 using postgresql-8.0-311.jdbc2.jar
Previous Message Oliver Jowett 2005-06-28 22:19:20 Re: getBinaryStream and OutOfMemoryException