Skip to content
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

Enum to handle exact number precisios #654

Merged
merged 1 commit into from Oct 8, 2022
Merged

Enum to handle exact number precisios #654

merged 1 commit into from Oct 8, 2022

Conversation

AugustoFKL
Copy link
Contributor

Implementation of an enum to handle Decimal (1) precision and scale, instead of options, for two reasons:

  • An enum is easier to access and handle. Options need to unwrap or errors even when you KNOW that an item should exist (e.g., DATETIME (p,s), if s is some, necessarily p is some).
  • Remove unwrap from our code. Even if they shouldn't happen, it's not nice to have unwrapped as "certainty" handlers (that was happening when we printed stuff).

Since we already didn't accept the DECIMAL data type only with scale, that doesn't change the behavior.

[1] : https://jakewheat.github.io/sql-overview/sql-2016-foundation-grammar.html#exact-numeric-type

@coveralls
Copy link

coveralls commented Oct 4, 2022

Pull Request Test Coverage Report for Build 3207622076

  • 30 of 33 (90.91%) changed or added relevant lines in 2 files are covered.
  • 2 unchanged lines in 1 file lost coverage.
  • Overall coverage increased (+0.02%) to 85.688%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/ast/data_type.rs 9 10 90.0%
src/parser.rs 21 23 91.3%
Files with Coverage Reduction New Missed Lines %
src/parser.rs 2 83.26%
Totals Coverage Status
Change from base Build 3207559008: 0.02%
Covered Lines: 10340
Relevant Lines: 12067

💛 - Coveralls

Copy link
Collaborator

@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.

Thanks @AugustoFKL

/// Additional information for `NUMERIC`, `DECIMAL`, and `DEC` data types
/// following the 2016 [standard].
///
/// [standard]: https://jakewheat.github.io/sql-overview/sql-2016-foundation-grammar.html#datetime-type
Copy link
Collaborator

Choose a reason for hiding this comment

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

this link seems incorrect (as it points to datetime-type)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed, thanks!

@@ -3467,10 +3467,9 @@ impl<'a> Parser<'a> {
Keyword::STRING => Ok(DataType::String),
Keyword::TEXT => Ok(DataType::Text),
Keyword::BYTEA => Ok(DataType::Bytea),
Keyword::NUMERIC | Keyword::DECIMAL | Keyword::DEC => {
let (precision, scale) = self.parse_optional_precision_scale()?;
Copy link
Collaborator

Choose a reason for hiding this comment

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

parse_optional_precision_scale

is this function still used anywhere? If not shall we remove it? If so, perhaps there are other places that should be migrated over?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is used in another place, in the parser as well. TBH I didn't review the logic for the other usage, maybe it ends in the same problem, but I'll take a look in another moment.

I think it can be left like that for now.

@alamb
Copy link
Collaborator

alamb commented Oct 7, 2022

Thanks @AugustoFKL

@alamb alamb merged commit a9939b0 into sqlparser-rs:main Oct 8, 2022
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.

None yet

3 participants