* Add basic support for GRANT privileges on tables and sequences
* Cargo fmt
* Make enum for granted privileges
* Implement and use Display for GrantObjects
* Simplify Display for GrantPrivileges
* Add column privileges
* Add second column privilege to test
* Add REVOKE privileges and reformat
* Fix some clippy warnings
* Fix more clippy
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
* Move the keywords mod from dialect mod into the root of library
Signed-off-by: koushiro <koushiro.cqx@gmail.com>
* re-export keywords from dialect for backwards compatiblity
Signed-off-by: koushiro <koushiro.cqx@gmail.com>
* Support TRIM syntax
- Implement the following cases
- TRIM([BOTH | LEADING | TRAILING] <expr> [FROM <expr>])
- TRIM(<expr>)
* Resolve 1.54.0 clippy error
- Remove needless borrow
* Add test cases for TRIM
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>
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
