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>
In MySQL it's AUTO_INCREMENT
(see https://dev.mysql.com/doc/refman/8.0/en/create-table.html)
and in SQLite it's AUTOINCREMENT.
We use `ColumnOption::DialectSpecific(Vec<Token>)` to avoid adding a new variant for each vendor-specific column option.
* Support create or replace table
* Support create or replace view
* Simplify create or replace table parser
* Add tests for create or replace external table and materialized view
* Formatting
* Address review comments
* Create error if we didn't see a (external) table or (materialized) view afer create or replace
This introduces a new section of the GitHub Actions workflow which will
publish the crate upon a new tag being pushed. Note that this requires a
new project secret, `CRATES_TOKEN`.
* update travis badge to point to actions status
It seems Travis is currently not updating as expected, likely as a side effect of the repo moving. If we're comfortable leaning on Actions, then we can switch out the badge here and plan to remove Travis entirely. Alternatively we could reconfigure Travis to work with the new repo name.
* Refer to correct branch
Co-authored-by: Dandandan <danielheres@gmail.com>
