Skip to content

Support more DateTimeField variants #1191

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

Merged
merged 1 commit into from
Apr 9, 2024
Merged

Conversation

iffyio
Copy link
Contributor

@iffyio iffyio commented Mar 23, 2024

@coveralls
Copy link

coveralls commented Mar 23, 2024

Pull Request Test Coverage Report for Build 8407785234

Details

  • 77 of 86 (89.53%) changed or added relevant lines in 6 files are covered.
  • 3 unchanged lines in 1 file lost coverage.
  • Overall coverage increased (+0.01%) to 87.882%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/parser/mod.rs 12 13 92.31%
tests/sqlparser_bigquery.rs 9 10 90.0%
src/ast/value.rs 39 46 84.78%
Files with Coverage Reduction New Missed Lines %
tests/sqlparser_common.rs 3 97.14%
Totals Coverage Status
Change from base Build 8266982631: 0.01%
Covered Lines: 20524
Relevant Lines: 23354

💛 - Coveralls

- Adds `DATETIME` variant to `DatetimeField`
- Adds support for snowflake abbreviations via `Custom` variant.
  https://docs.snowflake.com/en/sql-reference/functions-date-time#supported-date-and-time-parts
- Adds support for BigQuery weekday `WEEK(MONDAY)` syntax
  https://cloud.google.com/bigquery/docs/reference/standard-sql/date_functions#extract
@iffyio iffyio force-pushed the dateparts-support branch from 0df4a25 to cd640b9 Compare March 24, 2024 07:38
Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @iffyio (and I very much apologize for the delay in reviewing). The only thing I think this PR needs is to avoid creating intermediate strings in the Display fmt

})
f.write_str(
match self {
DateTimeField::Year => "YEAR".to_string(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change to call to_string() will now cause a new string to be allocated for each type.

I think it would be better / more effiicent to use write! directly -- like

Suggested change
DateTimeField::Year => "YEAR".to_string(),
match self {
DateTimeField::Year => f.write_str("YEAR"),
DateTimeField::Month => f.write_str("MONTH"),
...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes that makes a lot more sense, thanks for the follow up fix too!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(for anyone following along it was #1209)

@@ -12,6 +12,13 @@

#[cfg(not(feature = "std"))]
use alloc::string::String;

#[cfg(not(feature = "std"))]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you use the suggestion below I think you will not need these imports either

Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to keep the code flowing (and the fact it took me so long to review this PR) I fixed the string copy issue and pushed a fix to this PR.

Thanks again @iffyio

@alamb alamb merged commit 127be97 into apache:main Apr 9, 2024
@iffyio iffyio deleted the dateparts-support branch April 10, 2024 17:33
JichaoS pushed a commit to luabase/sqlparser-rs that referenced this pull request May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants