Hi Jeff,
I ran the test cases that you brought up with my very rough code changes
and the code seems to handle them all correctly.
Here is what happens in each of the cases
where t1.int_column + ? = - ?
The first parameter gets bound to the type of t1.int_column and then second
parameter gets bound to the same type too.
where t1.int_column = ? / - ?
This will not be accepted by Derby because both the operators for / are
parameters. In fact, if you tried the same query but without the unary
operator ie where t1.int_column = ? / ?, Derby will throw an exception that
both parameters around / can't be parameters.
where - ? not in (select t1.int_column + ? from . . .)
The second parameter gets the type of t1.int_column and then same type gets
assigned to the first parameter.
thanks,
Mamta
On 9/28/05, Jeffrey Lichtman <swazoo@rcn.com> wrote:
>
>
> >I agree with your and Dan's point about possible precision loss. I
> >am trying to find a way where rather than hard coding the -?/+? to
> >Double, try to get it's datatype from the context where it is used.
>
> There are circumstances where you can figure this out, but it's
> ambiguous in the general case. For example:
>
> where t1.int_column + ? = - ?
>
> Since both sides of the "=" operator have parameters, you can't use
> the type of one side to figure out the type of the other side.
>
> Here are some more examples of ambiguity:
>
> where t1.int_column = ? / - ?
>
> where - ? not in (select t1.int_column + ? from . . .)
>
> I don't think it's a good idea to try to solve this problem at all.
> There are a few cases where it's obvious what the type should be, and
> many more where it's not. There's also an easy workaround (use the
> CAST function). Even if we were able to figure out an algorithm to
> determine the type of a parameter in all cases, would it be possible
> to explain the behavior to an average user?
>
>
> - Jeff Lichtman
> swazoo@rcn.com
> Check out Swazoo Koolak's Web Jukebox at
> http://swazoo.com/
>
>
|