Thomas Hallgren wrote:
> Should this be considered a conscious flaw in the client driver
> motivated by the desire to limit the number of round trips? If it is,
> what would the best course of action be for me? Implement the same flaw
> although I don't have that problem?
There is considerably more to it than trying to avoid an extra
round-trip (although that is part of it). If we're given a String
parameter, why should we interpret it as anything other than a String?
We don't really want to implement an any-type-to-any-other-type
conversion routine in the driver!
Nevertheless there is a "fix" here -- pass "stringtype=unspecified" as a
URL parameter in the JDBC URL and the driver will pass parameters set
via setString() with unspecified types. This was originally put in to
handle apps that expected to be able to setString("42") on an int
column, but it should deal with your particular situation too. Use at
your own risk. See
http://jdbc.postgresql.org/documentation/head/connect.html#connection-parameters
Actually, one feature that might be nice in future protocol versions is
some ability to say "I think this parameter is one of these types --
please infer a type and fail to prepare if it doesn't match with the
expected types" which would also help with the timestamp-vs-timestamptz
case. Currently, we don't notice a mismatch between the value we passed
and the type that was inferred until well after the query is executed..
We could wait for a Describe before proceeding, but it seems a bit silly
if you can't do a decent implementation without sending Flush messages
everywhere, given the work the protocol does to let you stream messages
at it without waiting for results.
-O