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 https://github.com/ballista-compute/sqlparser-rs/issues/154
by (ab)using `TableFactor::NestedJoin` to represent anything nested in
extra set of parens.
Afterwards we learned in https://github.com/ballista-compute/sqlparser-rs/issues/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 #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 <eyal@satoricyber.com>
To share helper macros between various tests/* we added a new module
(tests/macros/mod.rs). This made the prologue to be used in tests quite
long and a little weird:
```
#[macro_use]
#[path = "macros/mod.rs"]
mod macros;
use sqlparser::test_utils::*;
```
This simplifies it to:
```
#[macro_use]
mod test_utils;
use test_utils::*;
```
- and switches all existing tests to the new prologue simultaneously...
...while fixing a few other inconsistencies and adding a few comments
about the way `test_utils` work.
SimpleLogger is private in v1.6. Bumping its version in Cargo.toml makes
`git pull && carg test` use the new version in an existing checkout
(with an existing Cargo.lock file referencing the old version)
The tags are named vX.Y, and we'll be 0.x for a while, so limiting the
publish-crate action to run v0 tags seems good enough to avoid
accidental publishes.
Since PR https://github.com/ballista-compute/sqlparser-rs/pull/93
`parse_column_def` parses a set of column options in a loop, e.g. given:
```
_______ column_def _______
CREATE TABLE foo (bar INT NOT NULL DEFAULT 1, )
-------- ---------
option 1 option 2
````
it parses column options until it encounters one of the delimiter tokens
First when we only supported `CREATE TABLE`, the set of delimiters that
stopped the parsing used to be `Token::Comma | Token::RParen`.
Then we added support for `ALTER TABLE ADD COLUMN <column_def>`. Turns
out the parser started to bail if the statement ended with a semicolon,
while attempting to parse the semicolon as a column option, as we forgot
to add it to the set of delimiter tokens.
This was recently fixed in https://github.com/ballista-compute/sqlparser-rs/pull/246
by including Token::SemiColon to the list, but it felt wrong to have
to update this list, and to have a common list of delimiters for two
different contexts (CREATE TABLE with parens vs ALTER TABLE ADD COLUMN
without parens).
Also our current approach cannot handle multiple statements NOT
separated by a semicolon, as is common in MS SQL DDL. We don't
explicitly support it in `parse_statements`, but that's a use-case
like to keep in mind nevertheless.
* Change `Parser { ... }` to store the dialect used:
`Parser<'a> { ... dialect: &'a dyn Dialect }`
Thanks to @c7hm4r for the initial version of this submitted as
part of https://github.com/ballista-compute/sqlparser-rs/pull/170
* Introduce `dialect_of!(parser is SQLiteDialect | GenericDialect)` helper
to branch on the dialect's type
* Use the new functionality to make `AUTO_INCREMENT` and `AUTOINCREMENT`
parsing dialect-dependent.
Co-authored-by: Christoph Müller <pmzqxfmn@runbox.com>
Co-authored-by: Nickolay Ponomarev <asqueella@gmail.com>
