Roughly the <character factor> production - https://jakewheat.github.io/sql-overview/sql-2011-foundation-grammar.html#character-factor
If an expression is followed by the keyword `COLLATE`, it must be
followed by the collation name, which is optionally schema-qualified
identifier.
The `COLLATE` keyword is not a regular binary operator in that it can't
be "nested": `foo COLLATE bar COLLATE baz` is not valid. If you prefer
to think of it as an operator, you might say it has the highest
precedence (judging from the spec), i.e. it binds to the smallest valid
expression to the left of it (so in `foo < bar COLLATE c`, the COLLATE
is applied first).
The `@@version` test is MS' dialect of SQL, it seems, so test it with
its own dialect.
Update the rules for identifiers in Postresql dialect per documentation,
while we're at it. The current identifier rules in Postgresql dialect
were introduced in this commit - as a copy of generic rules, it seems:
810cd8e6cf (diff-2808df0fba0aed85f9d35c167bd6a5f1L138)
1) Removed unused date/time parsing methods from `Parser`
I don't see how the token-based parsing code would ever be used: the
date/time literals are usually quoted, like `DATE 'yyyy-mm-dd'` or
simply `'YYYYMMDD'`, so the date will be a single token.
2) Removed unused date/time related variants from `Value` and the
dependency on `chrono`.
We don't support parsing date/time literals at the moment and when we
do I think we should store the exact String to let the consumer parse
it as they see fit.
3) Removed `parse_timestamps_example` and
`parse_timestamps_with_millis_example` tests. They parsed as
`number(2016) minus number(02) minus number(15) <END OF EXPRESSION>`
(leaving the time part unparsed) as it makes no sense to try parsing
a yyyy-mm-dd value as an SQL expression.
- ASTNode::SQLBinaryExpr is now constructed in one location
- There's no duplicate calls to parse_in/parse_between
- The list of tokens that correspond to operators is not duplicated
in parse_infix / to_sql_operator
- ...which made it easy to distinguish between errors that could be
caused by invalid input and internal errors. I switched the latter
to `panic!()`
We don't have the code to parse UUID literals, so it's dead code, that
brings in the dependency on `uuid`.
I kept SQLType::Uuid, as it's not dead code, though it ought to be
dialect-specific.
The name was confusing:
SQLStatement::SQLSelect(
SQLQuery {
body: SQLSetExpr::Select(SQLSelect)
}
)
Fix the `large_enum_variant` clippy lint for `SQLStatement::SQLQuery`
`SQLStatement::SQLCreateView`, and `SQLSetExpr::Select`, while we're
changing the AST anyway
https://rust-lang.github.io/rust-clippy/master/index.html#large_enum_variant
