[
https://issues.apache.org/jira/browse/FLINK-31661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709881#comment-17709881
]
Jark Wu commented on FLINK-31661:
---------------------------------
This can be a big effort because we need to contribute this feature to the
upstream project Calcite that the Calcite parser handles the ROW expression. In
addition, we need to investigate how/whether other mature database systems
support this.
> Add parity between `ROW` value function and it's type declaration
> -----------------------------------------------------------------
>
> Key: FLINK-31661
> URL: https://issues.apache.org/jira/browse/FLINK-31661
> Project: Flink
> Issue Type: Improvement
> Components: Table SQL / API
> Affects Versions: 1.17.0, 1.16.1, 1.18.0
> Reporter: Mohsen Rezaei
> Priority: Critical
>
> Currently the [{{ROW}} table
> type|https://nightlies.apache.org/flink/flink-docs-release-1.17/docs/dev/table/types/#row]
> allows for a name and type, and optionally a description, but [its value
> constructing
> function|https://nightlies.apache.org/flink/flink-docs-release-1.17/docs/dev/table/types/#row]
> only supports an arbitrary list of expressions.
> This prevents users from providing human-readable names for the fields
> provded to a {{ROW()}} or {{()}} value function call, resulting in
> system-defined {{EXPR$n}} names that lose their meaning as they are mixed in
> with other queries.
> For example, the following SQL query:
> {code}
> SELECT (id, name) as struct FROM t1;
> {code}
> results in the following consumable data type for the `ROW` column:
> {code}
> ROW<`EXPR$0` DECIMAL(10, 2), `EXPR$1` STRING> NOT NULL
> {code}
> I'd be happy to contribute to this change, but I need some guidance and
> pointers on where to start making changes for this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
