Pre-Reqs in SQL JSON Functions before improving NULL Support

[siddharthteotia]

Summary

I am working on improving NULL Support in JSON. I started that work directly upstream and it was based on top off some orthogonal refactoring in the JSON functions which is not available in the fork. The refactoring is important and I am porting it first to fork before creating the actual NULL feature work in JSON.

Capabilities added in this PR

• Users can supply default values in jsonExtractScalar calls
• More result types are supported: BOOLEAN, TIMESTAMP, JSON, BYTES
• BigDecimal precision is preserved through the JSON parser instead of being silently downcast
• Error messages on unsupported types are clearer

Commits (in order)

Upstream SHA	Upstream PR	What
f2153a1382	apache/pinot#16683	Handle null values in JsonExtractScalarTransformFunction with default value support
c297fbec3b	apache/pinot#17867	Enhance JSON extraction functions to support null handling in queries (introduces 3-arg init(..., boolean nullHandlingEnabled))
5cb954d578	apache/pinot#18429	Improve JsonExtractScalarTransformFunction: type coercion, BIG_DECIMAL_ARRAY, guards (introduces _dataType / _storedType fields + per-type literal extraction)

[siddharthteotia]

This is now ready for review. Once merged, #205 should be rebased on this and can be reviewed.

[UOETianleZhang]

Seems we are mostly cherry-picking from OSS. The only extra change 4ad3802 is minior and it LGTM.

There is an issue in OSS commits and I have left one comment on it. It is non-blocking, we can address it in a follow up PR.

[UOETianleZhang]

We are mentioning BYTES result type is supported but it will throw exception at runtime. This class never overrides transformToBytesValuesSV so it will call parent class's method BaseTransformFunction.transformToBytesValuesSV. In which an exception will be raised at runtime (BYTES has stored type BYTES, so it falls through to the base class):

  switch (resultDataType.getStoredType()) {                                                                                                                                                                                              
    case BIG_DECIMAL: ...                                                                                                                                                                                                                
    case STRING:      ...                                                                                                                                                                                                                
    case UNKNOWN:     ...                                                                                                                                                                                                                
    default:                                                                                                                                                                                                                             
      throw new IllegalStateException("Cannot read SV " + resultDataType + " as BYTES");                                                                                                                                                 
  }     

To fix it, we cab either implement transformToBytesValuesSV, or drop BYTES from the supported-types.

I am aware this issue is inherited from OSS, so we can also resolve it in a follow up PR.

[siddharthteotia]

Yes, 80% code is a cherry-pick. It's needed for a capability I am building in PR #205

Good catch. I will remove BYTES call out from supported types. Thanks for the review.