Skip to content

Fail to parse - "select * from (table_name)" #154

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

Closed
eyalleshem opened this issue Mar 31, 2020 · 7 comments
Closed

Fail to parse - "select * from (table_name)" #154

eyalleshem opened this issue Mar 31, 2020 · 7 comments

Comments

@eyalleshem
Copy link
Contributor

I think it's fail here - https://github.com/andygrove/sqlparser-rs/blob/master/src/parser.rs#L1797
because the code assume that inside the Parenthesis should be TableFactor::Derived or TableFactor::NestedJoin, but it's not take in account it's could be TableFactor::Table

@nickolay
Copy link
Contributor

from (table_name) is not actually valid SQL. Note that <table primary> in the ANSI SQL grammar does not allow parentheses around <table or query name>. A quick test shows that at least MS SQL Server follows the spec here. What database are you working with?

@eyalleshem
Copy link
Contributor Author

eyalleshem commented Mar 31, 2020

Thanks for the fast response :)

I tested against snowflake ..
Is that something that could be solve by building a dialect ?

@nickolay
Copy link
Contributor

Theoretically, yes. Practically in the current implementation the selected dialect only affects the tokenizer, and the parser unconditionally tries to parse some non-standard constructs.

@eyalleshem
Copy link
Contributor Author

So a code that support such syntax could be accepted?

@nickolay
Copy link
Contributor

I guess so, if it's going to be a simple change, that doesn't introduce problems parsing the standard syntax (this specific bit of the parser is quite complex as it is). @benesch what do you think?

@eyalleshem
Copy link
Contributor Author

well - i tried :)

@nickolay
Copy link
Contributor

PR #155 is now merged, closing this. Thanks!

nickolay added a commit to eyalleshem/sqlparser-rs that referenced this issue Oct 13, 2020
Snowflake diverges from the standard and from most of the other
implementations by allowing extra parentheses not only around a join,
but around lone table names (e.g. `FROM (mytable [AS alias])`) and
around derived tables (e.g. `FROM ((SELECT ...)  [AS alias])`) as well.

Initially this was implemented in apache#154
by (ab)using `TableFactor::NestedJoin` to represent anything nested in
extra set of parens.

Afterwards we learned in apache#223
that in cases of such extraneous nesting Snowflake allows specifying the
alias both inside and outside parens, but not both - consider:

    FROM (table_factor AS inner_alias) AS outer_alias

We've considered implementing this by changing `TableFactor::NestedJoin`
to a `TableFactor::Nested { inner: TableWithJoins, alias:
Option<TableAlias> }`, but that seemed too generic, as no known dialect
supports duplicate aliases, as shown above, nor naming nested joins
`(foo NATURAL JOIN bar) alias`. So we decided on making a smaller change
(with no modifications to the AST), that is also more appropriate to the
contributors to the Snowflake dialect:


1) Revert apache#154 by rejecting `FROM (table or derived table)` in most dialects.

2) For `dialect_of!(self is SnowflakeDialect | GenericDialect)` parse
and strip the extraneous parentheses, e.g.

   `(mytable) AS alias` -> `(mytable AS alias)`


Co-authored-by: Eyal Leshem <[email protected]>
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

No branches or pull requests

2 participants