>> I believe the original wire protocol only supported text values hence
>> the driver converts all data into a string before sending it to the
>> server... Because of this the server will generally convert any value
>> into the appropriate type (if this conversion is possible) which saves
>> the driver from doing so. This simplifies the driver at the expense of
>> extra network traffic and errors thrown by the server as opposed to the
>> driver. The original authors can probably expand on this
>>
>
> It is not clear to me: the driver is receiving always strings from the server,
> and therefore must do the conversion by itself. The fact is that such
> conversion is not checked against the table definition. I would expect an
> SQLException if I try to read an integer as a string or viceversa. Instead the
> conversion can work and the driver says nothing about.
>
For outgoing values, the current driver delays doing any work with the
query until it is actually executed. This has a number of consequences
and benefits which have been discussed before - see threads about
preparedstatements, etc. The double edged sword of this is that by
delaying execution the driver knows the types of the parameters being
passed in which can help planning, the downside is that it doesn't know
the types required so can't generate errors. While it is true that if
the query is fairly simple and done against a table then it could make
the check before submitting the query. But what does it do for queries
like this:
SELECT ?
The parameter can be of any type. Generally the argument is that you
cannot know the param types from the query itself.
However for incoming values/conversions, as oliver mentioned the JDBC
spec requires a driver do some conversions automatically (int -> string).
JOHN
