[
https://issues.apache.org/jira/browse/IGNITE-28690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-28690:
---------------------------------------
Description:
Some Ignite SQL extensions need to transform SQL expressions during the
`SqlNode` rewrite phase (IGNITE-27940).
This works well for purely structural rewrites or expressions that contain only
literals. However, it becomes problematic when the expression contains dynamic
parameters.
For example, an extension may need to transform an expression like:
{code:sql}
some_special_expression <= NVL(?, 100000)
{code}
into a different SQL shape where the parameter has to be moved to another part
of the query tree, or where the expression has to be replaced with a value
computed from the parameter.
Currently this is not safe or not possible:
* Replacing a parameter-dependent expression with a concrete value would be
incorrect because the prepared plan may be reused with different parameter
values.
* Moving an existing dynamic parameter to another place in the query tree may
fail validation/planning, depending on where the parameter is moved.
* The rewrite extension cannot introduce additional bind parameters together
with their runtime values.
A concrete example is Oracle-compatible ROWNUM support implemented in a plugin.
Simple literal-based cases can be rewritten, but parameter-based expressions
such as:
{code:sql}
ROWNUM <= ?
ROWNUM <= NVL(?, 100000)
{code}
cannot be correctly handled using the current SQL node rewrite extension alone.
was:
Some Ignite SQL extensions need to transform SQL expressions during the
`SqlNode` rewrite phase (IGNITE-27940).
This works well for purely structural rewrites or expressions that contain only
literals. However, it becomes problematic when the expression contains dynamic
parameters.
For example, an extension may need to transform an expression like:
{code:sql}
some_special_expression <= NVL(?, 100000)
{code}
into a different SQL shape where the parameter has to be moved to another part
of the query tree, or where the expression has to be replaced with a value
computed from the parameter.
Currently this is not safe or not possible:
* Replacing a parameter-dependent expression with a concrete value would be
incorrect because the prepared plan may be reused with different parameter
values.
* Moving an existing dynamic parameter to another place in the query tree may
fail validation/planning, depending on where the parameter is moved.
* The rewrite extension cannot introduce additional bind parameters together
with their runtime values.
*
A concrete example is Oracle-compatible ROWNUM support implemented in a plugin.
Simple literal-based cases can be rewritten, but parameter-based expressions
such as:
{code:sql}
ROWNUM <= ?
ROWNUM <= NVL(?, 100000)
{code}
cannot be correctly handled using the current SQL node rewrite extension alone.
> SQL node rewrite extension cannot safely transform expressions with dynamic
> parameters
> --------------------------------------------------------------------------------------
>
> Key: IGNITE-28690
> URL: https://issues.apache.org/jira/browse/IGNITE-28690
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Priority: Major
>
> Some Ignite SQL extensions need to transform SQL expressions during the
> `SqlNode` rewrite phase (IGNITE-27940).
> This works well for purely structural rewrites or expressions that contain
> only literals. However, it becomes problematic when the expression contains
> dynamic parameters.
> For example, an extension may need to transform an expression like:
> {code:sql}
> some_special_expression <= NVL(?, 100000)
> {code}
> into a different SQL shape where the parameter has to be moved to another
> part of the query tree, or where the expression has to be replaced with a
> value computed from the parameter.
> Currently this is not safe or not possible:
> * Replacing a parameter-dependent expression with a concrete value would be
> incorrect because the prepared plan may be reused with different parameter
> values.
> * Moving an existing dynamic parameter to another place in the query tree may
> fail validation/planning, depending on where the parameter is moved.
> * The rewrite extension cannot introduce additional bind parameters together
> with their runtime values.
> A concrete example is Oracle-compatible ROWNUM support implemented in a
> plugin. Simple literal-based cases can be rewritten, but parameter-based
> expressions such as:
> {code:sql}
> ROWNUM <= ?
> ROWNUM <= NVL(?, 100000)
> {code}
> cannot be correctly handled using the current SQL node rewrite extension
> alone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
