* feat: add DuckDB dialect
* formatting
* fix conflict
* support // in GenericDialect
* add DucDbDialect to all_dialects
* add comment from suggestion
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
* fix: support // in GenericDialect
---------
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
* feat: Add custom operator
From #863
- It doesn't parse anything — I'm not sure how to parse ` SELECT 'a' REGEXP '^[a-d]';` with `REGEXP` as the operator... (but fine for my narrow purpose)
- If we need tests, where would I add them?
* Update src/ast/operator.rs
---------
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
* Add a mutable visitor
This adds the ability to mutate parsed sql queries.
Previously, only visitors taking an immutable reference to the visited structures were allowed.
* add utility functions for mutable visits
* bump version numbers
* Add derive based AST visitor
* Fix BigDecimal
* Fix no visitor feature
* Add test
* Rename visit_table to visit_relation
* Review feedback
* Add pre and post visit
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
* Remove [not]like,[not]ilike from binary operator list
* Add like, ilike and similar as an expr variant. Also adds support for escape char to like/ilike
* Add parsing logic for similar to, update parsing logic for like/ilike
* Add tests for similar to, update tests for like/ilike
* Fix linter warnings
* remove additional copyright license from files
* Add more coverage w/wo escape char for like,ilike,similar to
* [postgres] Add support for custom binary operators
More details about operators in general are at:
https://www.postgresql.org/docs/current/sql-createoperator.html. This
patch attempts to parse `SELECT` queries that reference an operator
using `OPERATOR(<optional_schema>.<operator_name>)` syntax.
This is a PostgreSQL extension. There are no provisions for user-defined operators in the SQL standard.
* fix code-review comments and ci failures
* Allow custom operator in generic dialects too
* Parse `OPERATOR` as Vec<String>
* fix: std
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
It turns out implementing Hash alone is not very useful, as
std::collection::HashMap keys are required to implement both Hash and
Eq.
Co-authored-by: Nikhil Benesch <nikhil.benesch@gmail.com>
The rationale here is the same as the last commit: since this crate
exclusively parses SQL, there's no need to restate that in every type
name. (The prefix seems to be an artifact of this crate's history as a
submodule of Datafusion, where it was useful to explicitly call out
which types were related to SQL parsing.)
This commit has the additional benefit of making all type names
consistent; over type we'd added some types which were not prefixed with
"SQL".
