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

Enable map access for numbers, multiple nesting levels #356

Merged
merged 8 commits into from
Sep 24, 2021

Conversation

Igosuki
Copy link
Contributor

@Igosuki Igosuki commented Sep 16, 2021

This enables number based map access in the AST. I am unsure if this required a new type rather than just patching MapAccess but here goes.

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.

Thanks @Igosuki !

Looks good to me. FYI @hntd187 as MapAccess seems to have been introduced in #235

Broadly speaking looks compatible with https://www.postgresql.org/docs/9.1/arrays.html too

@@ -669,6 +672,26 @@ fn parse_pg_regex_match_ops() {
}
}

#[test]
fn parse_map_access_expr() {
//let sql = "SELECT foo[0] as foozero, bar[\"baz\"] as barbaz FROM foos";
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if you meant to leave this commented out

@@ -251,7 +251,7 @@ pub enum Expr {
},
MapAccess {
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we can improve the docstrings here while we are modifying this file?

@alamb
Copy link
Contributor

alamb commented Sep 16, 2021

This PR also adds support for multiple levels of map access as well, right? Like not just ["foo"] also ["foo"]["bar"]

Copy link
Member

@houqp houqp left a comment

Choose a reason for hiding this comment

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

LGTM, thanks @Igosuki !

@Igosuki
Copy link
Contributor Author

Igosuki commented Sep 17, 2021

@alamb yeah the point is to enable infinite levels of nesting, I should probably add a test for that with arbitrary nesting of n

@alamb alamb changed the title Enable map access for numbers Enable map access for numbers, multiple nesting levels Sep 17, 2021
@alamb
Copy link
Contributor

alamb commented Sep 17, 2021

looks like there are some CI tests to clean up as well @Igosuki FYI

@hntd187
Copy link
Contributor

hntd187 commented Sep 17, 2021

Looks good to me, I remember map access being something I was not entirely confident in for my initial work, but perhaps if one was able to extend it then it wasn't as bad as my own perception was of it.

@Igosuki
Copy link
Contributor Author

Igosuki commented Sep 18, 2021

Well, there will be occasions to expand upon this. For instance to support ranges, which are in the pg dialect (e.g. foo[1:2]). Also I think the display is wrong for map access regarding strings, because foo['bar'] and foo[bar] prints foo["'bar'"]
I added a test for string keys in map access as well to wrap it up.
Edit : ha but this breaks the hive dialect, which somehow doesn't print single quotes for a single quoted string

@Igosuki
Copy link
Contributor Author

Igosuki commented Sep 18, 2021

It breaks the hive test for map_access, since we don't differentiate between double and single quoted strings, I think this needs further fixing

@Igosuki
Copy link
Contributor Author

Igosuki commented Sep 24, 2021

Since map access belongs into the OLAP world and there is already the hive dialect, I went and enforced double quoted strings for map access in the display.

@Igosuki
Copy link
Contributor Author

Igosuki commented Sep 24, 2021

So now MapAccess is an infinite depth path access to nested values. I think allowing compound field selection within this should be a separate addition as it requires patching the tokenization so that '.' is allowed after brackets

@coveralls
Copy link

coveralls commented Sep 24, 2021

Pull Request Test Coverage Report for Build 1269308355

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

Details

  • 53 of 59 (89.83%) changed or added relevant lines in 4 files are covered.
  • 293 unchanged lines in 4 files lost coverage.
  • Overall coverage increased (+0.07%) to 90.135%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/ast/mod.rs 7 10 70.0%
src/parser.rs 14 17 82.35%
Files with Coverage Reduction New Missed Lines %
src/ast/operator.rs 2 93.02%
tests/sqlparser_common.rs 20 98.6%
src/parser.rs 134 85.86%
src/ast/mod.rs 137 70.82%
Totals Coverage Status
Change from base Build 1240364569: 0.07%
Covered Lines: 5820
Relevant Lines: 6457

💛 - Coveralls

src/ast/mod.rs Outdated
.map(|k| {
match k {
k @ Value::Number(_, _) => format!("[{}]", k),
Value::SingleQuotedString(s) => format!("[\"{}\"]", s),
Copy link
Contributor

Choose a reason for hiding this comment

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

It is odd to me that a SingleQuotedString is emitted with double quotes (") but it is consistent with the existing implementation

@alamb
Copy link
Contributor

alamb commented Sep 24, 2021

I think allowing compound field selection within this should be a separate addition as it requires patching the tokenization so that '.' is allowed after brackets

makes sense to me

@alamb
Copy link
Contributor

alamb commented Sep 24, 2021

FYI @Igosuki I fixed a CI failure with c9e3cfb

@alamb alamb merged commit d498887 into apache:main Sep 24, 2021
@Igosuki
Copy link
Contributor Author

Igosuki commented Sep 25, 2021 via email

@houqp
Copy link
Member

houqp commented Sep 25, 2021

Thank you for your work on this @Igosuki !

@Igosuki
Copy link
Contributor Author

Igosuki commented Sep 25, 2021 via email

@alamb
Copy link
Contributor

alamb commented Sep 26, 2021

Thanks, now to enable this in data fusion

See apache/datafusion#1052

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.

5 participants