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? Dan.
