[
https://issues.apache.org/jira/browse/FLINK-39049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18099777#comment-18099777
]
Jinkun Liu edited comment on FLINK-39049 at 7/29/26 1:35 AM:
-------------------------------------------------------------
Hello [~raminqaf] I’m +1 to lowering this ticket’s priority to Minor. Using
*CAST / TRY_CAST* on top of VARIANT navigation is definitely the more general
and reusable direction, and it aligns better with the overall type system.
That said, one nuance on the Flink side is that we don’t currently support *.*
access on VARIANT yet. In Flink’s existing design, dot access is typically used
for schema-known types (for example, {{STRUCTURED}} or {{{}ROW{}}}). I think if
we want to support dot access, it may need to depend on FLINK-37926, dot access
could first convert VARIANT to STRUCT, and then extract the field value.
So {{VARIANT_GET}} still has one practical benefit for now: it provides a
path-based access pattern (including graceful NULL behavior) before native
dot-style VARIANT access is fully available.
I’ve recently started working on this issue. Also happy to discuss alternative
designs if you have better ideas.
was (Author: JIRAUSER308530):
Hello [~raminqaf] I’m +1 to lowering this ticket’s priority to Minor. Using
*CAST / TRY_CAST* on top of VARIANT navigation is definitely the more general
and reusable direction, and it aligns better with the overall type system.
That said, one nuance on the Flink side is that we don’t currently support *.*
access on VARIANT yet. In Flink’s existing design, dot access is typically used
for schema-known types (for example, {{STRUCTURED}} or {{ROW}}), so extending
that behavior to semi-structured VARIANT data may be non-trivial.
So {{VARIANT_GET}} still has one practical benefit for now: it provides a
path-based access pattern (including graceful NULL behavior) before native
dot-style VARIANT access is fully available.
I’ve recently started working on this. Also happy to discuss alternative
designs if you have better ideas.
> Introduce built-in functions `VARIANT_GET` and `TRY_VARIANT_GET ` to extract
> values from a variant
> --------------------------------------------------------------------------------------------------
>
> Key: FLINK-39049
> URL: https://issues.apache.org/jira/browse/FLINK-39049
> Project: Flink
> Issue Type: Sub-task
> Components: Table SQL / API
> Reporter: Jinkun Liu
> Assignee: Jinkun Liu
> Priority: Minor
>
> ||SQL Function||Table Function||Description||
> |VARIANT_GET(variant, path RETURNING)|VARIANT.variantGet(variant, path,
> returnType])|Extracts a sub-value from a Variant using the specified path and
> casts it to the target type.
>
> If the path does not exist or is invalid, this function returns {{{}NULL{}}}.
> If the target return type is incompatible with the extracted value, this
> function throws an error.
>
> {{```sql}}
> {{-- TRUE}}
> {{VARIANT_GET(PARSE_JSON('\{"a": true}'), '$.a' RETURNING BOOLEAN)}}
>
> –- NULL
> {{VARIANT_GET(PARSE_JSON('\{"a": true}'), '$.b' RETURNING INT)}}
>
> {{-- throws: cannot cast VARIANT(STRING) to INT}}
> {{VARIANT_GET(PARSE_JSON('\{"a": "oops"}'), '$.a' RETURNING INT)}}
> {{```}}|
> |TRY_VARIANT_GET(variant, path RETURNING)|VARIANT.tryVariantGet(variant,
> path, returnType])|Similar to {{{}VARIANT_GET{}}}, but returns {{NULL}}
> instead of throwing an error when the extracted value cannot be cast to the
> target return type.
>
> If the path does not exist or is invalid, this function also returns
> {{{}NULL{}}}.|
> *reference：*
> [https://downloads.apache.org/spark/docs/4.2.0-preview3/api/sql/variant-functions/#try_variant_get]
> [https://docs.snowflake.com/en/sql-reference/functions/get]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
