[FLINK-40268][table] Add new JSON_TYPE function

[VasShabu]

What is the purpose of the change

This PR is adding the implementation of the builting function JSON_TYPE builtin function to Apache Flink.

(For example: This pull request makes task deployment go through the blob server, rather than through RPC. That way we avoid re-transferring them on each deployment (during recovery).)

Brief change log

(for example:)

• Added java codegen function
• Added function when after parsing will output the type of json
• Added docs (sql_functions.yml, sql_functions_zh.yml, BaseExpression.java, expression.py) to document how/what the function works/does.

Verifying this change

./mvnw -o -pl flink-table/flink-table-planner -Dtest='JsonFunctionsITCase' -Dsurefire.failIfNoSpecifiedTests=false -Dcheckstyle.skip=true -Dspotless.check.skip=true -e -Drat.skip=true -Denforcer.skip=true test

or (depending on version)

mvn -o -pl flink-table/flink-table-planner -Dtest='JsonFunctionsITCase' -Dsurefire.failIfNoSpecifiedTests=false -Dcheckstyle.skip=true -Dspotless.check.skip=true -e -Drat.skip=true -Denforcer.skip=true test

Please make sure both new and modified tests in this PR follow the conventions for tests defined in our code quality guide.

This change added tests and can be verified as follows:

(example:)

• Added JSON_TYPE functionality

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
• The serializers: (don't know)
• The runtime per-record code paths (performance sensitive): (yes)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (don't know)
• The S3 file system connector: (no)

Documentation

• Does this pull request introduce a new feature? (yes)
• If yes, how is the feature documented? (docs / JavaDocs ). (sql_function.yml/expression.py)

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

[flinkbot]

CI report:

• 8511671 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[gustavodemorais]

General feedback after the first pass

JSON itself only knows six kinds of value: object, array, string, number, boolean, and null. That's it - there's no such thing as a "date" or a "float" in JSON. So if someone writes {"d": "2015-01-01"}, that d is a string that happens to look like a date. The PR guesses and reports DATE, and similarly guesses FLOAT vs DOUBLE based on how precise the number is. Our recommendation is not to guess: just report what's actually there.

Other databases sometimes do report DATE, which is why this looks like precedent - but they can only do it because they store JSON in their own typed format, so a real date got written in as a real date. Flink is handed a plain string of text, which carries no such information. And it matters practically: if you write CASE JSON_TYPE(x) WHEN 'STRING' THEN ..., every date-looking string silently skips your branch. Reporting the six real types keeps the answer both true, predictable and useful. We want to implement this in a way it's useful for typical use cases: users reach for it to branch on fields whose shape varies - a payload where errors is sometimes a string, sometimes an array. For that, following the json native way is a simpler and sufficient.

That said, some concrete suggestions:

• Add an optional path: JSON_TYPE(json [, path]).
• Cut to JSON's six types: OBJECT ARRAY STRING NUMBER BOOLEAN 'NULL'. The input is a VARCHAR; it carries nothing more.
• Drop DATE and FLOAT - that's sniffing, not typing, and no engine does it.
• Fold INTEGER/LONG into NUMBER
• Also, think about VARIANT story - TYPEOF(PARSE_JSON(...)) returns 'VARIANT', so we risk two vocabularies for one question