[jira] [Updated] (FLINK-31661) Add parity between `ROW` value function and it's type declaration
[
https://issues.apache.org/jira/browse/FLINK-31661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Qingsheng Ren updated FLINK-31661:
--
Priority: Major (was: Critical)
> 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: Major
>
> 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)
[jira] [Updated] (FLINK-31661) Add parity between `ROW` value function and it's type declaration
[
https://issues.apache.org/jira/browse/FLINK-31661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jark Wu updated FLINK-31661:
Component/s: Table SQL / API
(was: API / DataSet)
> 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)
[jira] [Updated] (FLINK-31661) Add parity between `ROW` value function and it's type declaration
[
https://issues.apache.org/jira/browse/FLINK-31661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Visser updated FLINK-31661:
---
Fix Version/s: (was: 1.18.0)
(was: 1.17.1)
> 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: API / DataSet
>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)
[jira] [Updated] (FLINK-31661) Add parity between `ROW` value function and it's type declaration
[
https://issues.apache.org/jira/browse/FLINK-31661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohsen Rezaei updated FLINK-31661:
--
Description:
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.
was:
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:
```
SELECT (id, name) as struct FROM t1;
```
results in the following consumable data type for the `ROW` column:
```
ROW<`EXPR$0` DECIMAL(10, 2), `EXPR$1` STRING> NOT NULL
```
I'd be happy to contribute to this change, but I need some guidance and
pointers on where to start making changes for 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: API / DataSet
>Affects Versions: 1.17.0, 1.16.1, 1.18.0
>Reporter: Mohsen Rezaei
>Priority: Critical
> Fix For: 1.18.0, 1.17.1
>
>
> 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)
