Examples of org.voltdb.expressions.AbstractExpression.refineValueType()

• org.voltdb.expressions.AbstractExpression.refineValueType()
  Specify or specialize the type and optionally the maximum size of an expression value. This is used when the expression's type or size is implied or constrained by its usage, especially to match the type/size of a target column in an INSERT or UPDATE statement. This default implementation is currently a no-op, which covers expressions whose value type/size is pre-determined, like logical expressions, comparisons, tuple address expressions, etc. Derived classes define custom implementations typically to allow refinement of types or sizes for expressions that the HSQL parser was unable to determine the type of, leaving the type as null, or was only able to narrow down to NUMERIC (of some undetermined type). Type refinement can have an effect on the interpretation of constant values. E.g. is this constant string being used as a timestamp? If so, a compile-time check for a valid date/time format could provide a valuable heads-up to the user. It also can bolster parameter type checking. E.g. should values for this parameter only be allowed in the tiny int range? @param neededType - the target type of the value as suggested by its usage. @param neededSize - the maximum allowed size for the value as suggested by its usage.TODO: we might want to enable asserts when we appear to be trying to refine a type or size on an expression that expects to have a fixed pre-determined type -- at least when non-trivially trying to refine the type/size to something other than its current type/size. The ONLY reason this default no-op implementation contains any code at all is to make it easier to catch such cases in a debugger, possibly in preparation for a more agressive assert.