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

Add support for SHOW DATABASES/SCHEMAS/TABLES/VIEWS in Hive #1487

Merged
merged 6 commits into from
Nov 3, 2024

Conversation

yoavcloud
Copy link
Contributor

This PR adds support for the above statements in the Hive dialect, making the previously MySQL-only structs a bit more generic.

src/ast/mod.rs Outdated
let keyword = match &db_name_keyword {
Some(Keyword::FROM) => "FROM",
Some(Keyword::IN) => "IN",
_ => "", // unexpected
Copy link
Member

Choose a reason for hiding this comment

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

Can use unreachable!() to panic if it's an unexpected condition.

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

src/ast/mod.rs Outdated
let keyword = match &db_name_keyword {
Some(Keyword::FROM) => "FROM",
Some(Keyword::IN) => "IN",
_ => "", // unexpected
Copy link
Member

Choose a reason for hiding this comment

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

Same as the above comment.

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

@@ -534,6 +534,20 @@ fn parse_use() {
);
}

#[test]
fn test_show() {
hive().verified_stmt("SHOW DATABASES");
Copy link
Member

Choose a reason for hiding this comment

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

It would be better to use hive_and_generic since it also works for generic dialects.

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

@yoavcloud yoavcloud force-pushed the hive_show_tables_in branch from 17aa53f to 9249aa3 Compare October 30, 2024 05:47
@yoavcloud yoavcloud requested a review from git-hulk October 30, 2024 05:48
db_name: None,
filter: Some(ShowStatementFilter::Where(
mysql_and_generic().verified_expr("1 = 2")
)),
}
);
mysql_and_generic().one_statement_parses_to("SHOW TABLES IN mydb", "SHOW TABLES FROM mydb");
mysql_and_generic().verified_stmt("SHOW TABLES IN mydb");
mysql_and_generic().verified_stmt( "SHOW TABLES FROM mydb");
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
mysql_and_generic().verified_stmt( "SHOW TABLES FROM mydb");
mysql_and_generic().verified_stmt("SHOW TABLES FROM mydb");

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

@yoavcloud yoavcloud requested a review from git-hulk October 30, 2024 06:04
Copy link
Member

@git-hulk git-hulk left a comment

Choose a reason for hiding this comment

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

LGTM, cc @iffyio

hive_and_generic().verified_stmt("SHOW SCHEMAS LIKE '%abc'");
hive_and_generic().verified_stmt("SHOW TABLES");
hive_and_generic().verified_stmt("SHOW TABLES IN db1");
hive_and_generic().verified_stmt("SHOW TABLES IN db1 'abc'");
Copy link
Contributor

Choose a reason for hiding this comment

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

for tables/views in addition to IN can we also include testcases for FROM?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, according to the hive docs, it's only for views though.

@@ -534,6 +534,20 @@ fn parse_use() {
);
}

#[test]
Copy link
Contributor

Choose a reason for hiding this comment

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

thinking we can move this test over to common? the current code isn't specific to hive and the feature/syntax seems popular enough that the parser can always accept it as it does today

Copy link
Contributor Author

@yoavcloud yoavcloud Oct 31, 2024

Choose a reason for hiding this comment

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

I understand the preference now is for the parser to err on the side of accepting statements even if the dialect doesn't actually support them right? If so, then yes, we can move the tests to common. The SHOW syntax is somewhat popular but it's not a standard.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah we have a few scenarios where the parser accepts input that isn't supported by the dialect. I figured here it could be easier to do so just as well, the alternative would be to add explicit methods to the dialect trait i.e dialect.supports_show_databases() dialect.supports_show_schemas() etc which I think would also be fine if that's preferrable from an impl pov

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Kept it at the generic level. I have some more SHOW statements for Snowflake to add, so we'll see if these challenge this decision.

src/ast/mod.rs Outdated
Comment on lines 4412 to 4419
if let Some(db_name) = db_name {
write!(f, " FROM {db_name}")?;
let keyword = match &db_name_keyword {
Some(Keyword::FROM) => "FROM",
Some(Keyword::IN) => "IN",
_ => unreachable!(),
};
write!(f, " {} {db_name}", keyword)?;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think representation wise we can represent the IN/FROM explicitly? e.g.

enum ShowClause {
   IN,
   FROM
}
Statement::ShowViews{ clause: Option<ShowClause>, db_name: Option<Ident> }

The unreachable panic I don't think fits well here since there's no invariant guarding that panic (the parser codepath is quite far away from this and could possibly change subtly to trigger it), I think it'd be reasonable as in the previous version to display an incorrect sql (which would be less consequential given we have a bug vs than crash the user's service). Though in this case likely we can rely on the compiler to make such a state unavoidable via the enum route.

Also would it make more sense to skip the nested if let since the db_name and db_name_keyword are set independently. as in

if let Some(db_name_keyword) = db_name_keyword {
    write(f, " {db_name_keyword}")?;
}
if let Some(db_name) = db_name {
    write(f, " {db_name})?;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good comments, with the ShowClause the unreachable dilemma is irrelevant

src/ast/mod.rs Outdated
@@ -2782,12 +2783,30 @@ pub enum Statement {
filter: Option<ShowStatementFilter>,
},
/// ```sql
/// SHOW DATABASES [LIKE 'pattern']
/// ```
ShowDatabases { pattern: Option<String> },
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it make sense to also use ShowStatementFilter to represent this (if there's a chance that the syntax can be extended)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great idea

@yoavcloud yoavcloud requested a review from iffyio October 31, 2024 22:37
Copy link
Contributor

@iffyio iffyio left a comment

Choose a reason for hiding this comment

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

LGTM! cc @alamb

@coveralls
Copy link

coveralls commented Nov 1, 2024

Pull Request Test Coverage Report for Build 11632792517

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

  • 91 of 95 (95.79%) changed or added relevant lines in 4 files are covered.
  • 3 unchanged lines in 2 files lost coverage.
  • Overall coverage increased (+0.02%) to 89.396%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/ast/mod.rs 32 36 88.89%
Files with Coverage Reduction New Missed Lines %
src/ast/mod.rs 1 82.14%
src/dialect/postgresql.rs 2 73.5%
Totals Coverage Status
Change from base Build 11580333290: 0.02%
Covered Lines: 30500
Relevant Lines: 34118

💛 - Coveralls

@yoavcloud
Copy link
Contributor Author

Sorry, did a last change and forgot cargo fmt... Changes committed now, if you can run the CI again that would be great @alamb

@alamb alamb enabled auto-merge (squash) November 1, 2024 20:41
@alamb
Copy link
Contributor

alamb commented Nov 1, 2024

🚀

@yoavcloud
Copy link
Contributor Author

@iffyio @alamb why isn't this merged?

@alamb
Copy link
Contributor

alamb commented Nov 3, 2024

@iffyio @alamb why isn't this merged?

Sorry -- am behind.

@alamb alamb merged commit e2197ee into apache:main Nov 3, 2024
10 checks passed
@yoavcloud
Copy link
Contributor Author

Thank you!

wugeer pushed a commit to wugeer/sqlparser-rs that referenced this pull request Nov 5, 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.

5 participants