Re: [Fwd: Re: [Pljava-dev] char with trailing space, PreparedStatement.setObject

[Oliver Jowett <oliver(at)opencloud(dot)com>]

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