Thread: JDBCCTS issues
Does anyone know what the spec says if a parameter is registered and the underlying type is not the same as the registered type? for instance registerOutParameter( n, Types.Real ) where the underlying type is float8 In general should we be attempting to convert to the case requested ? The particular example above is required for the test to pass. Dave Dave Cramer davec@postgresintl.com www.postgresintl.com ICQ #14675561 jabber davecramer@jabber.org ph (519 939 0336 )
Dave Cramer wrote: > Does anyone know what the spec says if a parameter is registered and > the underlying type is not the same as the registered type? > > for instance registerOutParameter( n, Types.Real ) where the underlying > type is float8 > > In general should we be attempting to convert to the case requested ? Ok I stared at the spec a bit.. It seems like the type you specify when registering is the type you intend to retrieve via a get...() method, and the spec seems to imply that the driver should cast the parameter to that type.. but it's vague as usual. The datatype conversion tables appendix does not talk about datatype conversion on CallableStatement.get...() at all (though it does talk about conversion in ResultSet). So I suppose we should probably accept it and do a cast to the appropriate type on return. Am I right in thinking that OUT parameter types aren't considered part of a function's signature and don't contribute to overloading at all? -O
On 5-Jul-05, at 7:05 PM, Oliver Jowett wrote: > Dave Cramer wrote: > >> Does anyone know what the spec says if a parameter is registered and >> the underlying type is not the same as the registered type? >> >> for instance registerOutParameter( n, Types.Real ) where the >> underlying >> type is float8 >> >> In general should we be attempting to convert to the case requested ? >> > > Ok I stared at the spec a bit.. > > It seems like the type you specify when registering is the type you > intend to retrieve via a get...() method, and the spec seems to imply > that the driver should cast the parameter to that type.. but it's > vague > as usual. > > The datatype conversion tables appendix does not talk about datatype > conversion on CallableStatement.get...() at all (though it does talk > about conversion in ResultSet). > > So I suppose we should probably accept it and do a cast to the > appropriate type on return. I don't think anyone will mind if we make it easier for them. > > Am I right in thinking that OUT parameter types aren't considered part > of a function's signature and don't contribute to overloading at all? At the moment that is true, yes > > -O > >