-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IGNITE-24227 Sql. Improve type checking in LIMIT / OFFSET clauses #5479
base: main
Are you sure you want to change the base?
Conversation
@@ -700,34 +700,48 @@ private void checkIntegerLimit(@Nullable SqlNode n, String nodeName) { | |||
} | |||
|
|||
if (n instanceof SqlLiteral) { | |||
BigDecimal offFetchLimit = ((SqlLiteral) n).bigDecimalValue(); | |||
BigDecimal offsetFetchLimit = ((SqlLiteral) n).bigDecimalValue(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's also improve method's javadoc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
} | ||
|
||
if (param instanceof BigDecimal) { | ||
checkLimitOffset((BigDecimal) param, n, nodeName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no point in validation of particular value of dynamic parameter on preparation stage since validation is happening once, and then plan will be reused for different arguments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
got it, move into execution phase
# decimal limit | ||
query I | ||
SELECT a FROM test ORDER BY a LIMIT 1.6 | ||
---- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we can check FETCH .... ROWS
syntax as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -1158,4 +1144,20 @@ private static boolean canFuseProjectionInto(RelNode rel) { | |||
|
|||
return joinProjection; | |||
} | |||
|
|||
private long validateAndGetFetchOffsetParams(RexNode node, String op) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably we can move this check into Node code and append additional tests if it helpful with another issue?
Thank you for submitting the pull request.
To streamline the review process of the patch and ensure better code quality
we ask both an author and a reviewer to verify the following:
The Review Checklist
- There is a single JIRA ticket related to the pull request.
- The web-link to the pull request is attached to the JIRA ticket.
- The JIRA ticket has the Patch Available state.
- The description of the JIRA ticket explains WHAT was made, WHY and HOW.
- The pull request title is treated as the final commit message. The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
Notes