Support TRIM function parameters
#3007
Conversation
Codecov Report
@@ Coverage Diff @@
## main #3007 +/- ##
===========================================
+ Coverage 99.94% 100.00% +0.05%
===========================================
Files 164 164
Lines 11981 11997 +16
===========================================
+ Hits 11974 11997 +23
+ Misses 7 0 -7
Continue to review full report at Codecov.
|
| bracketed: | ||
| - start_bracket: ( | ||
| - expression: | ||
| column_reference: |
There was a problem hiding this comment.
Is it an issue that these are appearing as column references?
There was a problem hiding this comment.
Good spot. That shouldn't happen. Looking...
| @@ -943,6 +944,13 @@ class QualifiedNumericLiteralSegment(BaseSegment): | |||
| Ref("ExpressionSegment"), | |||
| # A Cast-like function | |||
| Sequence(Ref("ExpressionSegment"), "AS", Ref("DatatypeSegment")), | |||
| # Trim function | |||
| Sequence( | |||
There was a problem hiding this comment.
Are we checking the function name, or can this be used with any function? Seems like the latter. Any concerns with allowing that?
There was a problem hiding this comment.
Yeah I thought about that. You're right we do allow with any function. But very specific set of syntax and grammar so think will only match that.
This who FunctionContentsGrammar is made up of lots of syntax types that could be specific to certain function names but isn't, and this PR continues that theme.
To limit it to certain function names would require a change similar to #3004 where we get around it being a keyword (so it's still a function name type). But that gets messy and potentially unmaintainable pretty quickly. Hence I did initially implement #3004 in a similar manner to this. However, as that was specific to BigQuery, and similar to another pattern in Function I changed my mind on that.
For this TRIM one, I think we follow the previous pattern, as more generic and unlikely to match incorrectly.
Brief summary of the change made
Fixes #1935
Are there any other side effects of this change that we should be aware of?
These seem to be supported in many dialects. For those that don't support this I've overridden the Grammar to
Nothing()to prevent it trying to find Keywords that don't exist.Pull Request checklist
Please confirm you have completed any of the necessary steps below.
Included test cases to demonstrate any code changes, which may be one or more of the following:
.ymlrule test cases intest/fixtures/rules/std_rule_cases..sql/.ymlparser test cases intest/fixtures/dialects(note YML files can be auto generated withtox -e generate-fixture-yml).test/fixtures/linter/autofix.Added appropriate documentation for the change.
Created GitHub issues for any relevant followup/future enhancements if appropriate.