mirror of
https://github.com/apache/datafusion-sqlparser-rs.git
synced 2025-08-02 13:12:16 +00:00
66505ebf9e
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. |
||
|---|---|---|
| .. | ||
| queries/tpch | ||
| sqlparser_common.rs | ||
| sqlparser_mssql.rs | ||
| sqlparser_mysql.rs | ||
| sqlparser_postgres.rs | ||
| sqlparser_regression.rs | ||
| sqlparser_sqlite.rs | ||