sql: make errors point to recorded view commands #13445
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
teskje
commented
Jul 5, 2022
|
Mind holding off on this one for a day, @teskje? I want to see if I can use this as motivation to plumb |
|
@benesch Of course! |
benesch
added a commit
to benesch/materialize
that referenced
this pull request
Jul 5, 2022
Most of the functions still produce only PlanError::Unstructured, but this will allow us to incrementally move each error to a structured error type. This allows the error structure to be propagated upwards to the coordinator when it exists, which will allow the structured SQL errors to return hints and long form descriptions. In particular, after this change, the error messages under construction in MaterializeInc#13445 will be able to properly emit hints.
1 task
|
Ok, done in #13455! |
benesch
added a commit
to benesch/materialize
that referenced
this pull request
Jul 5, 2022
Most of the functions still produce only PlanError::Unstructured, but this will allow us to incrementally move each error to a structured error type. This allows the error structure to be propagated upwards to the coordinator when it exists, which will allow the structured SQL errors to return hints and long form descriptions. In particular, after this change, the error messages under construction in MaterializeInc#13445 will be able to properly emit hints.
benesch
added a commit
to benesch/materialize
that referenced
this pull request
Jul 5, 2022
Most of the functions still produce only PlanError::Unstructured, but this will allow us to incrementally move each error to a structured error type. This allows the error structure to be propagated upwards to the coordinator when it exists, which will allow the structured SQL errors to return hints and long form descriptions. In particular, after this change, the error messages under construction in MaterializeInc#13445 will be able to properly emit hints.
benesch
added a commit
that referenced
this pull request
Jul 5, 2022
Most of the functions still produce only PlanError::Unstructured, but this will allow us to incrementally move each error to a structured error type. This allows the error structure to be propagated upwards to the coordinator when it exists, which will allow the structured SQL errors to return hints and long form descriptions. In particular, after this change, the error messages under construction in #13445 will be able to properly emit hints.
When a user tries to use regular view commands (DROP VIEW, SHOW CREATE VIEW, ALTER VIEW) on recorded views, point them to the correct RECORDED VIEW commands in the error messages.
teskje
force-pushed
the
recorded-view-friendly-errors
branch
from
140be90 to
c946920
Compare
|
cc @philip-stoev: This solves item no. 2, 3, and 5 from #13346. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a user tries to use regular view commands (
DROP VIEW,SHOW CREATE VIEW,ALTER VIEW) on recorded views, point them to the correct RECORDED VIEW commands in the error messages.Motivation
Part of MaterializeInc/database-issues#3692.
Tips for reviewer
The error messages are not optimal, because we lack the ability to returnAdapterErrors inside thesqlcode (see my inline comment for more detail). If someone can think of a way to improve this without completely refactoring the crate's error handling, let me know!Testing
Release notes
This PR includes the following user-facing behavior changes: