Skip to content

Clean up string-related variants in Token and Value #36

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 4 commits into from
Mar 8, 2019

Conversation

nickolay
Copy link
Contributor

At this moment there are Value::String, Value::SingleQuotedString, and Value::DoubleQuotedString and corresponding Token variants (plus a separate Token::Identifier).

Of these

  • double-quoted string is not a string literal, so there should be only a Token of that type, not Value (a866fbc).
  • Token/Value::String is mostly unused and doesn't make much sense to me (b8ea37c / 9b5a222)

Which leaves Value::SingleQuotedString, Token::SingleQuotedString, and Token::DoubleQuotedString, for a 50% reduction! :)

@coveralls
Copy link

coveralls commented Jan 12, 2019

Pull Request Test Coverage Report for Build 111

  • 6 of 7 (85.71%) changed or added relevant lines in 2 files are covered.
  • 2 unchanged lines in 1 file lost coverage.
  • Overall coverage increased (+0.3%) to 83.579%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/sqlast/mod.rs 1 2 50.0%
Files with Coverage Reduction New Missed Lines %
src/sqlast/value.rs 2 43.48%
Totals Coverage Status
Change from base Build 108: 0.3%
Covered Lines: 2555
Relevant Lines: 3057

💛 - Coveralls

Indeed, given that there is Token::SingleQuotedString and
Token::Identifier, there's no other "string" that would make sense...
An identifier is not a literal value, and parse_value is not called on
such a token anyway.
...and parser support for the corresponding token, as "..." in SQL[*] is
not a literal string like we parse it - but a quoted identifier (which I
intend to implement later).

[*] in all the RBDMSes I know, except for sqlite which has complex rules
in the name of "compatibility": https://www.sqlite.org/lang_keywords.html
Its existence alongside SingleQuotedString simply doesn't make sense:
`'a string'` is a string literal, while `a string` is not a "value".

It's only used in postgresql-specific tab-separated-values parser to
store the string representation of a field's value. For that use-case
Option<String> looks like a more appropriate choice than Value.
Copy link
Member

@andygrove andygrove left a comment

Choose a reason for hiding this comment

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

More good cleanup. Thank you.

@andygrove andygrove merged commit 73f55fe into apache:master Mar 8, 2019
@nickolay nickolay deleted the strings branch March 8, 2019 13:39
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