Re: jdbc cts final diff for review

On 30-Jun-05, at 8:56 PM, Oliver Jowett wrote:

> Dave Cramer wrote:
>
>> Did you read my reasons for the ugly if double, then float stuff ?
>>
>
> Haven't had time to get my head around that yet.. can you translate it
> to an explanation of something in the JDBC spec that we don't do
> correctly? It's a bit hard to understand what's going wrong without
> the
> CTS code to hand..

If you consider that Oracle doesn't have a FLOAT4 type this is a non-
issue for them
they will always convert a FLOAT8 to a java float if that is what is
registered, and they
will never have an issue storing a large integer into a FLOAT type.

Not that "Oracle doesn't do it" is a good argument, but I would
imagine they were instrumental
in the creation of the test suite.

FWIW, the spec, and the CTS aren't always in agreement. I have
pointed out the
issues to them, and finally gave up, the CTS is the defacto standard,
regardless of it's short comings

I'll try to dig around for the actual tests that failed later

>
>
>> I think it can be removed, however I think sooner than later we
>> will  be
>> dealing
>> with more complex parameters when stored procedures with real IN/
>> OUT  parms
>>
>
> Well, let's add the complexity only when we need it..
I still want to push this in the way it is and we can hack on it
until 8.1 goes out
>
>
>>> I still think they are redundant and should be entirely removed.
>>> We  can
>>> do that afterwards though.
>>>
>>
>> If absolutely necessary, however I don't think setObject with a
>> different type is
>> in the critical path
>>
>
> I'll hack on it if I have time after this is all applied; don't worry
> about it for now since it's already in HEAD.
>
>
>>> Why the repackaging?
>>>
>>
>> can't remember now.
>>
>
> Can you avoid repackaging then? Less CVS churn..

Absolutely
>
> -O
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that
> your
>        message can get through to the mailing list cleanly
>
>