Don't lose precision when parsing decimal fractions

The SQL standard requires that numeric literals with a decimal point,
like 1.23, are represented exactly, up to some precision. That means
that parsing these literals into f64s is invalid, as it is impossible
to represent many decimal numbers exactly in binary floating point (for
example, 0.3).

This commit parses all numeric literals into a new `Value` variant
`Number(String)`, removing the old `Long(u64)` and `Double(f64)`
variants. This is slightly less convenient for downstream consumers, but
far more flexible, as numbers that do not fit into a u64 and f64 are now
representable.
This commit is contained in:
Nikhil Benesch 2019-07-08 14:15:16 -04:00
parent 2bef9ec30a
commit b5621c0fe8
No known key found for this signature in database
GPG key ID: FCF98542083C5A69
5 changed files with 82 additions and 77 deletions

View file

@ -163,7 +163,7 @@ fn parse_create_table_with_defaults() {
vec![
SqlOption {
name: "fillfactor".into(),
value: Value::Long(20)
value: Value::Number("20".into())
},
SqlOption {
name: "user_catalog_table".into(),
@ -171,7 +171,7 @@ fn parse_create_table_with_defaults() {
},
SqlOption {
name: "autovacuum_vacuum_threshold".into(),
value: Value::Long(100)
value: Value::Number("100".into())
},
]
);