Skip to content

Support CREATE TABLE with no columns #94

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 1 commit into from
Jun 4, 2019

Conversation

benesch
Copy link
Contributor

@benesch benesch commented Jun 3, 2019

This is weird, but supported by PostgreSQL.

This is weird, but supported by PostgreSQL.
@benesch benesch requested a review from nickolay June 3, 2019 03:50
@coveralls
Copy link

coveralls commented Jun 3, 2019

Pull Request Test Coverage Report for Build 245

  • 4 of 4 (100.0%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 90.102%

Totals Coverage Status
Change from base Build 234: 0.0%
Covered Lines: 3350
Relevant Lines: 3718

💛 - Coveralls

Copy link
Contributor

@nickolay nickolay left a comment

Choose a reason for hiding this comment

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

Weird indeed and definitely not standard.

I wonder what you think of my idea about being explicit about which dialect has to support which constructs. I.e. I'd put this test into sqlparser_postgres and ran it with pg_and_generic().

To be clear: I don't ask you to move the test, rather wondering what you think about organizing the tests in such a way and if you'd object to moving it there at a later point.

@benesch
Copy link
Contributor Author

benesch commented Jun 4, 2019

To be clear: I don't ask you to move the test, rather wondering what you think about organizing the tests in such a way and if you'd object to moving it there at a later point.

I'm very much in favor in that! I almost wonder if we should aim for dialects to explicitly reject syntax they don't support. I.e., perhaps we should be explicitly testing that CREATE TABLE t () returns an error on all the non-Postgres dialects.

@benesch benesch merged commit fdbf64c into apache:master Jun 4, 2019
@nickolay nickolay mentioned this pull request Jun 9, 2019
@benesch benesch deleted the empty-create-table branch June 21, 2019 22:34
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