* 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>
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.
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>
* 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 implements `DROP [ COLUMN ] [ IF EXISTS ] column_name [ CASCADE ]`
sub-command of `ALTER TABLE`, which is what PostgreSQL supports https://www.postgresql.org/docs/12/sql-altertable.html
(except for the RESTRICT option)
Co-authored-by: Nickolay Ponomarev <asqueella@gmail.com>
Fixes#168 by enabling `DATE` and other keywords to be used as
identifiers when not followed by a string literal.
A "typed string" is our term for generalized version of `DATE '...'`/`TIME '...'`/
`TIMESTAMP '...'` literals, represented as `TypedString { data_type, value }`
in the AST.
Unlike DATE/TIME/TIMESTAMP literals, this is a non-standard extension
supported by PostgreSQL at least.
This is a port of MaterializeInc/materialize#3146
Co-authored-by: Nikhil Benesch <nikhil.benesch@gmail.com>
Co-authored-by: Nickolay Ponomarev <asqueella@gmail.com>
Alter INTERVAL to support postgres syntax
This patch updates our INTERVAL implementation such that the Postgres
and Redshfit variation of the syntax is supported: namely that 'leading
field' is optional.
Fixes#177.
