feat: Error when a SHOW command is passed in with an accompanying non-existant variable #11540
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.
Which issue does this PR close?
Closes #11529
Rationale for this change
This is a very simple implementation for the change suggested in #11529, and is easy to review and comprehend.
What changes are included in this PR?
This causes datafusion to return an error when someone attempts to execute a command that contains a
SHOW
statement whose variable does not exist in theinformation_schema.df_settings
table. This provides a better UX for the user, as they get told exactly what's going on (with a clear error) when they execute this command, instead of getting an empty table as the result (which was happening previously).Are these changes tested?
Yes - Additions were made to the sqllogictest tests to cover the use case addressed here.
Are there any user-facing changes?
I think this counts as a user-facing change - it would be easy to rely on the behavior of "SHOW will return an empty result if doesn't exist" and so it's very possible someone does rely on that.
I'd be happy to update documentation if that's necessary with this change, though I'm somewhat uncertain as to whether this warrants that - the previous behavior wasn't specified in docs, so I don't know if it is necessary here. It probably couldn't hurt, I think.