db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <msat...@gmail.com>
Subject Re: [PATCH] (DERBY-582) Dynamic parameter should be allowed to be the operand of unary operator "-". Derby throws exception 42X36: The '-' operator is not allowed to take a ? parameter as an operand."
Date Thu, 29 Sep 2005 07:22:33 GMT
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/
>
>

Mime
View raw message