SQL: Defer context-based decisions to rule runtime.#18097
SQL: Defer context-based decisions to rule runtime.#18097gianm wants to merge 1 commit intoapache:masterfrom
Conversation
SET statements (apache#17894) provide a new way to set query context. However, they are not available at the time that the planner is constructed, which means they are not available when rules are built. Certain rules are built based on the context, which means SET was unable to affect them. This patch fixes the problem by deferring context-based decisions from rule creation time to rule runtime.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
|
||
| public DeferredProjectMergeRule(PlannerContext plannerContext) | ||
| { | ||
| super(operand(Project.class, operand(Project.class, any()))); |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation Note
|
|
||
| public DeferredProjectMergeRule(PlannerContext plannerContext) | ||
| { | ||
| super(operand(Project.class, operand(Project.class, any()))); |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation Note
|
|
||
| public DeferredProjectMergeRule(PlannerContext plannerContext) | ||
| { | ||
| super(operand(Project.class, operand(Project.class, any()))); |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation Note
|
On further reflection I think this is still a not-ideal approach. It would be better to parse the SQL immediately as soon as we get the request, so even properties like |
2 participants
SET statements (#17894) provide a new way to set query context. However, they are not available at the time that the planner is constructed, which means they are not available when rules are built. Certain rules are built based on the context, which means SET was unable to affect them.
This patch fixes the problem by deferring context-based decisions from rule creation time to rule runtime.