-
-
Notifications
You must be signed in to change notification settings - Fork 218
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
prevent panic on triggers with declare statements #2442
Conversation
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.
we chatted a bit about this, but if the goal is to not panic I think it might be safest/easiest to explicitly error in planbuilder when we're building a handler without an appropriate trigger context. Pushing it downstream risk undefined behavior or more panics
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, thanks for refactoring a bit. I think the errors here are nicely self-documenting.
sql/expression/procedurereference.go
Outdated
return &ProcedureParam{ | ||
name: strings.ToLower(name), | ||
typ: typ, | ||
//pRef: NewProcedureReference(), |
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.
undo?
We're reusing a code from stored procedures to handle begin end blocks, but we're missing a lot of set up that prevents certain variables from being nil. Consequently, we panic in a couple places.
This PR fixes some of those panics, but reveals other problems we have in resolving/executing triggers of this format.
Partially addresses: dolthub/dolt#7720