Standardize the license header, removing the Grove Enterprise copyright
notice where it exists per #58. Also add a CI check to ensure that files
without license headers don't get merged.
Fix#58.
It is convenient for downstream libraries to be able to stash bits of
ASTs into hash maps, e.g., for performing simple common subexpression
elimination.
The only downside to this change is that it requires that the f64 in the
Value enum be wrapped in an OrderedFloat, which provides the necessary
equality semantics to allow Hash to be drived. The reason f64 doesn't
implement Hash by default is because NaN is typically not equal to
itself, so it's not clear what it should hash to. That's less of a
concern in a SQL context, because every SQL database I've looked at
treats NaN as equal to itself, in violation of the IEEE standard, in
order to permit indexing and sorting of float columns.
The tokenizer emits a separate Token for +/- signs, so the value of
Value::Long() (as well as of parse_literal_int()) may never be negative.
Also we have been using both u64 and usize to represent a parsed
unsigned number. Change to using u64 for consistency.
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.
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.
Its existence alongside SingleQuotedString simply doesn't make sense:
`'a string'` is a string literal, while `a string` is not a "value".
It's only used in postgresql-specific tab-separated-values parser to
store the string representation of a field's value. For that use-case
Option<String> looks like a more appropriate choice than Value.
...and parser support for the corresponding token, as "..." in SQL[*] is
not a literal string like we parse it - but a quoted identifier (which I
intend to implement later).
[*] in all the RBDMSes I know, except for sqlite which has complex rules
in the name of "compatibility": https://www.sqlite.org/lang_keywords.html
