Hi Jeff,
 
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.
 
For instance, say there is a table t1 with columns c11 as decimal(2,1) and c12 as int, Then for following sql
select * from t1 where c11 = -? and c12 = +?
The first parameter should be bound to decimal and the second parameter should be bound to int.
 
Looking at the code for UnaryOperatorNode/UnaryArithmeticOperatorNode, it seems like it is going to be tricky to pass on the datatype of the left operand in above example to UnaryArithmeticOperator.
 
Some info about current code flow for the specific example above and one possible generic solution
BinaryOperatorNode.bindExpression calls bindExpression on the left operand (line 307 in the code) and then on the right operand (UnaryArithmeticOperatorNode). The right operand at this point doesn't know what type it should be bound to. In my preliminary changes, I am making the bindExpression no-op for UnaryArithmeticOperatorNode if it has a parameter operand which is not bound to any type yet. Later in BinaryOperatorNode.bindExpression (line 335), the right operand gets bound to the same type as the left operand through the setDescriptor call, which is what we want. Once we have the correct type, we now want to run bindExpression on the UnaryArithmeticOperator. In my changes, I am overriding the setDescriptor method in UnaryArithmeticOperatorNode and having it call the bindExpression after it sets the type of the parameter to the left operand's type. Calling bindExpression will run all the bind time rules that should be run on a UnaryArithmeticOperatorNode. I haven't run enough tests to know if this is full proof but looking from outside, does anyone think there is a better solution than this? Even if my changes work fine, they seem more like a hack because during the actual bindExpression call, I am treating it as a no-op and then forcing the bindExpression later when UnaryArithmeticOperator does get the correct type. Any feedback from the community on this will be great.
 
thanks,
Mamta

 
On 9/28/05, Jeffrey Lichtman <[EMAIL PROTECTED]> wrote:

>I have a simple patch to allow dynamic parameters for unary minus
>and plus. The parameter will be bound to DOUBLE. The patch is
>attached to JIRA. Can a commiter please commit it if everything
>looks good? I have run all the tests and no new failures. Have also
>added a test for this.

I'm not convinced this is a good idea.

The SQL standard limits the use of parameters to those places where
their types can be determined unambiguously, for example, in an
insert or update list, or as an argument to the CAST function. I
don't know of any general way to figure out what the type of a
parameter "should" be in other places, especially for overloaded
functions and operators like - (both unary and binary).

What will happen if Cloudscape binds a parameter to a double, and the
user tries to use it with a fixed-point type like decimal? It's
likely there will be a loss of precision, and the user won't get what
he expects.

If the user wants to use a parameter with unary minus, I suggest the
use of the cast function to make the type unambiguous:

  - (cast ? as <type>)


                       -        Jeff Lichtman
                                [EMAIL PROTECTED]
                                Check out Swazoo Koolak's Web Jukebox at
                                http://swazoo.com/


Reply via email to