-
Notifications
You must be signed in to change notification settings - Fork 594
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
feat(sql-udf): add hint display for non-existent functions #15188
feat(sql-udf): add hint display for non-existent functions #15188
Conversation
Current dependencies on/for this PR: This stack of pull requests is managed by Graphite. |
474d9c9
to
60e90b0
Compare
60e90b0
to
ce30232
Compare
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.
LGTM.
Having a highlight of invalid tokens is definitely cool. But the implementation looks more and more hacky to me. I think we should start investigating on the span-based solutions. 🥵
ErrMsgType::Parameter => invalid_msg.split_whitespace().last(), | ||
// e.g., function <target name> does not exist | ||
ErrMsgType::Function => { | ||
let func = invalid_msg.split_whitespace().nth(1).unwrap_or("null"); |
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.
Is it possible to extract targets directly from error types, instead of relying on formatted error messages?
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.
Error type can not indicate [function / invalid parameter] name I'm assuming, so it seems impossible? 🥵
enum ErrMsgType { | ||
Parameter, | ||
Function, |
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.
Can we associate identifier names in this enum? This way, validate_err_msg
and extract_hint_display_target
can be merged into one.
enum ErrMsgType { | |
Parameter, | |
Function, | |
enum ErrMsgType { | |
Parameter(String), | |
Function(String), |
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.
Actually I don't think this two could merge. 🤔
Without prior context on what the error message is for, we can't simply retrieve the hint target from the input message.
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Checklist
./risedev check
(or alias,./risedev c
)Documentation
Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.