[
https://issues.apache.org/jira/browse/FLINK-24311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ingo Bürk updated FLINK-24311:
------------------------------
Description:
For JSON construction functions such as JSON_OBJECT, we currently disable
expression reduction. This is because these functions have special semantics
where they behave differently depending on their call context. For example,
JSON_OBJECT returns a JSON string. This means that a call like
{code:java}
JSON_OBJECT('A' VALUE JSON_OBJECT('B' VALUE 'C')){code}
would result in
{code:java}
{"A": "{\"B\": \"C\"}"}{code}
However, this is not user-friendly, and thus such nested calls are treated
differently and instead result in the likely more intended outcome
{code:java}
{"A": {"B": "C"}}{code}
To make this work, the function looks at its operands and checks whether each
operand is another RexCall to such a JSON construction function. If it is, it
inserts it as a raw node instead.
This creates a problem during expression reduction. The RexCall will be
replaced with a RexLiteral carrying the JSON string value. The function looking
at the operands now cannot determine that this originated from such a RexCall
anymore, and yields the unintended result once again. To prevent this, we
currently disable expression reduction for these functions.
We should aim to once again allow such expressions to be reduced while still
preserving the intended behavior. See [this
comment|https://github.com/apache/flink/pull/17186#issuecomment-920783089] for
a rough idea of how this could be achieved.
was:
For JSON construction functions such as JSON_OBJECT, we currently disable
expression reduction. This is because these functions have special semantics
where they behave differently depending on their call context. For example,
JSON_OBJECT returns a JSON string. This means that a call like
{code:java}
JSON_OBJECT('A' VALUE JSON_OBJECT('B' VALUE 'C')){code}
would result in
{code:java}
{"A": "{\"B\": \"C\"}"}{code}
However, this is not user-friendly, and thus such nested calls are treated
differently and instead result in the likely more intended outcome
{code:java}
{"A": {"B": "C"}}{code}
To make this work, the function looks at its operands and checks whether each
operand is another RexCall to such a JSON construction function. If it is, it
inserts it as a raw node instead.
This creates a problem during expression reduction. The RexCall will be
replaced with a RexLiteral carrying the JSON string value. The function looking
at the operands now cannot determine that this originated from such a RexCall
anymore, and yields the unintended result once again. To prevent this, we
currently disable expression reduction for these functions.
We should aim to once again allow such expressions to be reduced while still
preserving the intended behavior. See [this
comment|https://github.com/apache/flink/pull/17186#issuecomment-920783089] for
a rough idea of how this could be achieved.
> Support expression reduction for JSON construction functions
> ------------------------------------------------------------
>
> Key: FLINK-24311
> URL: https://issues.apache.org/jira/browse/FLINK-24311
> Project: Flink
> Issue Type: Sub-task
> Components: Table SQL / API
> Reporter: Ingo Bürk
> Priority: Major
>
> For JSON construction functions such as JSON_OBJECT, we currently disable
> expression reduction. This is because these functions have special semantics
> where they behave differently depending on their call context. For example,
> JSON_OBJECT returns a JSON string. This means that a call like
> {code:java}
> JSON_OBJECT('A' VALUE JSON_OBJECT('B' VALUE 'C')){code}
> would result in
> {code:java}
> {"A": "{\"B\": \"C\"}"}{code}
> However, this is not user-friendly, and thus such nested calls are treated
> differently and instead result in the likely more intended outcome
> {code:java}
> {"A": {"B": "C"}}{code}
> To make this work, the function looks at its operands and checks whether each
> operand is another RexCall to such a JSON construction function. If it is, it
> inserts it as a raw node instead.
> This creates a problem during expression reduction. The RexCall will be
> replaced with a RexLiteral carrying the JSON string value. The function
> looking at the operands now cannot determine that this originated from such a
> RexCall anymore, and yields the unintended result once again. To prevent
> this, we currently disable expression reduction for these functions.
> We should aim to once again allow such expressions to be reduced while still
> preserving the intended behavior. See [this
> comment|https://github.com/apache/flink/pull/17186#issuecomment-920783089]
> for a rough idea of how this could be achieved.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
