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
Enum to handle exact number precisios #654
Conversation
Pull Request Test Coverage Report for Build 3207622076
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @AugustoFKL
src/ast/data_type.rs
Outdated
/// 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 |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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()?; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Thanks @AugustoFKL |
Implementation of an enum to handle Decimal (1) precision and scale, instead of options, for two reasons:
DATETIME (p,s)
, ifs
is some, necessarilyp
is some).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