anchor.diff:  
   === Alternatives
   
  -Columns in SQL are always have a concrete type. This removes the need to define a global sort order between types. Standard SQL has no support for lists, maps, or graph structures and hence does not need to define semantics for them.
  +Columns in SQL always have a concrete type. This removes the need to define a global sort order between types. Standard SQL has no support for lists, maps, or graph structures and hence does not need to define semantics for them.
   SQL also treats comparisons involving `null` as returning `null`.
   
  -PostgresSQL treats some numerical operations (like division by zero) that would compute a `NaN` as a numerical error that fails the query. PostgresQL considers `NaN` to be larger than positive infinity, both in comparison and in sort order. This proposal achieves something very similar by evaluating comparisons involving a `NaN` to `null` and by treating both `NaN` and `null` as the largest values in the global sort order.
  +PostgresSQL treats some numerical operations (such as division by zero) that would compute a `NaN` as a numerical error that causes the query to fail. PostgresQL considers `NaN` to be larger than positive infinity, both in comparison and in sort order. This proposal achieves something very similar by evaluating comparisons involving a `NaN` to `null` and by treating both `NaN` and `null` as the largest values in the global sort order.
   
   This proposal could be extended with an operator for making equivalence accessible beyond use in grouping and `DISTINCT`. This seems desirable due to plain `=` not being reflexive for all values.
   
  
positive.code: a1 = b1 && a2 = b2 && ...
  ----
  
  For clarity, we also repeat the current equality semantics of maps here (at the time of writing this CIP). Two maps `m1` and `m2` are considered equal if
  
  * `m1` and `m2` must have the same keys.
  * For each key `k`,
  ** either `m1.k = m2.k` is `true`,
  ** or both `m1.k IS NULL` and `m2.k IS NULL`
  
  This is at odds with the common interpretation of `null` as standing for any possible value.
  
  It is aligned though with the most common use case for maps with `null` entries which is to update multiple properties at once, e.g. `SET n += { n: 12, remove_this_key: null }`. In this case, there is no need to differentiate between different `null` values as `null` merely serves as a marker for keys to be removed. Current equality semantics makes it easy to check if two maps correspond to the same property update in this scenario.
  
  However this type of update map comparison is rare and could be emulated using a more complex predicate. The current rules do however break symmetry with how equality handles `null` in all other cases. This becomes more apparent by considering these two examples
  
  * `expr1 = expr2` => `null` if `expr1 IS null && expr2 IS NULL`
  * `{a: expr1} = {a: expr2}` => `true` (!!) if `expr1 IS null && expr2 IS NULL`
  
  To fix this, we propose that two maps `m1` and `m2` instead should be equal if
  
  * `m1` and `m2` have the same keys (the order of keys as returned by `keys` does not matter)
  * For each such key `k`, `m1.k = m2.k`
  
  As a consequence of these changes, plain equality is not reflexive in a classic sense (Consider: `{a: null} = {a: null}`, `[null] = [null]`). However this was already the case (Consider: `null = null` => `null`).
  
  However, Equality is reflexive for values that do not involve `null`.
  
  === Equivalence ===
  
  
negative.code: 
  === Comparability
  
  We propose that comparability be defined between any pair of values, as specified below (please note that `null` is interpreted as meaning "unknown" or "could be any value" in the context of comparability):
  
  * Integers are compared numerically.
  * Floats (excluding `NaN` and the Infinities) are compared numerically.
  * Numbers of different types (excluding `NaN` and the Infinities) are compared to each other numerically, i.e. the comparison behaves as if both numbers would have been coerced to arbitrary precision big decimals (currently outside the Cypher type system) before comparing them with each other numerically.
  * Positive infinity is of type `FLOAT`, equal to itself and larger than any other number (excluding `NaN`).
  * Negative infinity is of type `FLOAT`, equal to itself and smaller than any other number (excluding `NaN`).
  * Comparing a number to a `NaN` always yields `null`.
  