Let me go back to the example sql
select * from t1 where c1 = -?
BinaryOperatorNode.bindExpression checks if right operand is a parameter node and if yes, it CASTS the right operand to ParameterNode and calls setDescriptor method on it.
  /* Is there a ? parameter on the right? */
  if (rightOperand.isParameterNode())
   /* Set the right operand to the type of the left parameter. */
   ((ParameterNode) rightOperand).setDescriptor( leftOperand.getTypeServices());
This casting of a parameter operand to ParameterNode and setting the descriptor on it is spread all over Derby engine code and rather than having to change them all, I decided to make UnaryOperatorNode extend ParameterNode so the rest of the type setting code can work without any change.
It's possible that I have been thinking single track, so if anyone have any suggestions, do let me know.

On 10/5/05, Daniel John Debrunner <djd@debrunners.com> wrote:
Mamta Satoor wrote:

> This patch tries to support the type setting of unary-/unary+ parameter
> similar to what is done for ? parameter ie the type of the -?/+? will be
> dependent on the context in which it is used. And hence the type setting
> rules for -?/+? will be same as for a regular ? parameter.
> In order to achieve this, I have changed UnaryOperatorNode to extend
> ParameterNode. In addition, it has the method isParameterNode which will
> return true only if its operand is an instance of ParameterNode and it's
> method isParameterNode returns true AND the unary operator is of the
> type unary-/unary+. What this means is that just because a class is
> instance of ParameterNode doesn't automatically mean it indeed is a
> ParameterNode. An additional check of the isParameterNode is required to
> make sure there is a parameter underneath. This change in rule has
> required adding a new class called HasParameterNodeVisitor which gets
> used by the sqlgrammar to make sure there are no parameters allowed in
> views and triggers. HasParameterNodeVisitor checks if the node is of the
> type ParameterNode AND checks if the isParameterNode returns true. If
> yes, then the HasParameterNodeVisitor's visit method will return that
> node and grammar will throw an exception for parameter usage in
> views/triggers.

Thanks for the detailed explanations.

I'm a little unclear why this making UnaryOperatorNode extend
ParameterNode and the subsequent changes are needed. Currently
triggers/views can check to see if the statement has a parameter node
anywhere in the tree without having every node implement ParameterNode,
so what is different about UnaryOperatorNode now?

Or maybe to ask a different way, why does the current searching for
parameters break if UnaryOperatorNode has a parameter as its argument?