   Compiling nxcypher v0.1.0 (/Users/gregoriomomm/workspace/ica/nxcypher-networkit)
warning: unused import: `indexmap::IndexMap`
 --> src/executor/context.rs:5:5
  |
5 | use indexmap::IndexMap;
  |     ^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: unused import: `std::collections::HashMap`
 --> src/executor/evaluator.rs:3:5
  |
3 | use std::collections::HashMap;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^

warning: unused imports: `NodeValue`, `PathValue`, and `RelationshipValue`
  --> src/executor/evaluator.rs:14:5
   |
14 |     NodeValue, PathValue, RelationshipValue, TimeValue,
   |     ^^^^^^^^^  ^^^^^^^^^  ^^^^^^^^^^^^^^^^^

warning: unused import: `indexmap::IndexMap`
 --> src/executor/functions/scalar.rs:5:5
  |
5 | use indexmap::IndexMap;
  |     ^^^^^^^^^^^^^^^^^^

warning: unused doc comment
  --> src/executor/functions/temporal.rs:13:1
   |
13 | / /// Thread-local cache for temporal "now" values.
14 | | /// Within a single query execution, temporal functions like datetime(), localtime(), etc.
15 | | /// should return the same value when called with no arguments. This cache holds the
16 | | /// current "now" value that's used throughout the query.
   | |_--------------------------------------------------------^
   |   |
   |   rustdoc does not generate documentation for macro invocations
   |
   = help: to document an item produced by a macro, the macro must produce the documentation as part of its expansion
   = note: `#[warn(unused_doc_comments)]` on by default

warning: unused import: `ExtendedLocalDateTimeValue`
 --> src/executor/functions/temporal.rs:5:78
  |
5 |     CypherValue, DateTimeValue, DateValue, DurationValue, ExtendedDateValue, ExtendedLocalDateTimeValue,
  |                                                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: unused import: `Datelike`
    --> src/executor/functions/temporal.rs:2682:18
     |
2682 |     use chrono::{Datelike, Timelike};
     |                  ^^^^^^^^

warning: unused import: `chrono::Datelike`
    --> src/executor/functions/temporal.rs:2842:9
     |
2842 |     use chrono::Datelike;
     |         ^^^^^^^^^^^^^^^^

warning: unused import: `chrono::Datelike`
    --> src/executor/functions/temporal.rs:3086:21
     |
3086 |                 use chrono::Datelike;
     |                     ^^^^^^^^^^^^^^^^

warning: unused import: `chrono::Datelike`
    --> src/executor/functions/temporal.rs:3103:21
     |
3103 |                 use chrono::Datelike;
     |                     ^^^^^^^^^^^^^^^^

warning: unused imports: `Datelike`, `NaiveTime`, and `Timelike`
    --> src/executor/functions/temporal.rs:3248:18
     |
3248 |     use chrono::{Datelike, Timelike, NaiveTime};
     |                  ^^^^^^^^  ^^^^^^^^  ^^^^^^^^^

warning: unused imports: `Datelike`, `NaiveDateTime`, and `NaiveTime`
    --> src/executor/functions/temporal.rs:3299:18
     |
3299 |     use chrono::{Datelike, Timelike, NaiveTime, NaiveDateTime, NaiveDate};
     |                  ^^^^^^^^            ^^^^^^^^^  ^^^^^^^^^^^^^

warning: unused import: `HashMap`
 --> src/executor/pattern_matcher.rs:3:24
  |
3 | use std::collections::{HashMap, HashSet};
  |                        ^^^^^^^

warning: unused import: `functions::AggregateAccumulator`
    --> src/executor/mod.rs:1330:13
     |
1330 |         use functions::AggregateAccumulator;
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: unused import: `AggregateAccumulator`
    --> src/executor/mod.rs:1410:36
     |
1410 |         use functions::aggregate::{AggregateAccumulator, create_accumulator};
     |                                    ^^^^^^^^^^^^^^^^^^^^

warning: unused import: `ExecutionError`
 --> src/graph/backend.rs:8:20
  |
8 | use crate::error::{ExecutionError, ExecutionResult};
  |                    ^^^^^^^^^^^^^^

warning: unused imports: `EdgeId as NKEdgeId` and `Weight`
  --> src/graph/backends/networkit_rust/backend.rs:14:60
   |
14 | use super::graph::{Graph, GraphConfig, NodeId as NKNodeId, EdgeId as NKEdgeId, Weight};
   |                                                            ^^^^^^^^^^^^^^^^^^  ^^^^^^

warning: unused import: `rustc_hash::FxHashMap`
  --> src/graph/backends/networkit_rust/algorithms/distance.rs:13:5
   |
13 | use rustc_hash::FxHashMap;
   |     ^^^^^^^^^^^^^^^^^^^^^

warning: unused import: `Weight`
  --> src/graph/backends/networkit_rust/algorithms/distance.rs:15:42
   |
15 | use super::super::graph::{Graph, NodeId, Weight};
   |                                          ^^^^^^

warning: unused import: `rustc_hash::FxHashMap`
  --> src/graph/backends/networkit_rust/algorithms/centrality.rs:12:5
   |
12 | use rustc_hash::FxHashMap;
   |     ^^^^^^^^^^^^^^^^^^^^^

warning: unused import: `rustc_hash::FxHashSet`
  --> src/graph/backends/networkit_rust/algorithms/components.rs:11:5
   |
11 | use rustc_hash::FxHashSet;
   |     ^^^^^^^^^^^^^^^^^^^^^

warning: unused imports: `GraphEdge` and `GraphNode`
 --> src/result/value.rs:9:30
  |
9 | use crate::graph::{EdgeLike, GraphEdge, GraphNode, NodeLike, Path, PropertyValue};
  |                              ^^^^^^^^^  ^^^^^^^^^

warning: unused import: `Utc`
 --> src/result/temporal.rs:8:15
  |
8 |     Timelike, Utc,
  |               ^^^

warning: unused import: `chrono::Timelike`
   --> src/executor/evaluator.rs:232:13
    |
232 |         use chrono::Timelike;
    |             ^^^^^^^^^^^^^^^^

warning: unused import: `chrono::Timelike`
   --> src/executor/evaluator.rs:268:13
    |
268 |         use chrono::Timelike;
    |             ^^^^^^^^^^^^^^^^

warning: unused import: `Timelike`
   --> src/executor/evaluator.rs:294:32
    |
294 |         use chrono::{Datelike, Timelike};
    |                                ^^^^^^^^

warning: unused import: `Timelike`
   --> src/executor/evaluator.rs:355:32
    |
355 |         use chrono::{Datelike, Timelike};
    |                                ^^^^^^^^

warning: unused import: `chrono::Timelike`
    --> src/executor/functions/temporal.rs:3090:21
     |
3090 |                 use chrono::Timelike;
     |                     ^^^^^^^^^^^^^^^^

warning: unused import: `chrono::Timelike`
    --> src/executor/functions/temporal.rs:3107:21
     |
3107 |                 use chrono::Timelike;
     |                     ^^^^^^^^^^^^^^^^

warning: unused import: `EdgeLike`
  --> src/executor/mod.rs:25:20
   |
25 | use crate::graph::{EdgeLike, GraphBackend, NodeLike, PropertyValue};
   |                    ^^^^^^^^

warning: value assigned to `min_explicit` is never read
    --> src/ast/builder.rs:1015:17
     |
1015 |         let mut min_explicit = false;
     |                 ^^^^^^^^^^^^
     |
     = help: maybe it is overwritten before being read?
     = note: `#[warn(unused_assignments)]` on by default

warning: variable does not need to be mutable
   --> src/executor/functions/temporal.rs:861:65
    |
861 | ...   let (base_date, mut base_time, mut base_offset, mut datetime_source_tz_name) = if let Some(base) = components.get("datetime") {
    |                                                       ----^^^^^^^^^^^^^^^^^^^^^^^
    |                                                       |
    |                                                       help: remove this `mut`
    |
    = note: `#[warn(unused_mut)]` on by default

warning: variable does not need to be mutable
   --> src/graph/backends/networkit_rust/graph.rs:213:17
    |
213 |             let mut out_vec = Vec::with_capacity(avg_degree);
    |                 ----^^^^^^^
    |                 |
    |                 help: remove this `mut`

warning: unused variable: `id`
   --> src/graph/backends/networkit_rust/backend.rs:226:32
    |
226 |     fn get_node_mut(&mut self, id: u64) -> Option<&mut GraphNode> {
    |                                ^^ help: if this is intentional, prefix it with an underscore: `_id`
    |
    = note: `#[warn(unused_variables)]` on by default

warning: unused variable: `component_sizes`
   --> src/graph/backends/networkit_rust/algorithms/components.rs:132:17
    |
132 |         let mut component_sizes: Vec<usize> = Vec::new();
    |                 ^^^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_component_sizes`

warning: variable does not need to be mutable
   --> src/graph/backends/networkit_rust/algorithms/components.rs:132:13
    |
132 |         let mut component_sizes: Vec<usize> = Vec::new();
    |             ----^^^^^^^^^^^^^^^
    |             |
    |             help: remove this `mut`

warning: associated function `build_binary_expr_right_assoc` is never used
    --> src/ast/builder.rs:1169:8
     |
  36 | impl AstBuilder {
     | --------------- associated function in this implementation
...
1169 |     fn build_binary_expr_right_assoc(
     |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: `#[warn(dead_code)]` on by default

warning: function `get_int_component` is never used
  --> src/executor/functions/temporal.rs:40:4
   |
40 | fn get_int_component(map: &IndexMap<String, CypherValue>, key: &str) -> ExecutionResult<i64> {
   |    ^^^^^^^^^^^^^^^^^

warning: method `filter_where` is never used
   --> src/executor/subquery.rs:212:8
    |
 18 | impl<'a, G: GraphBackend> SubqueryExecutor<'a, G> {
    | ------------------------------------------------- method in this implementation
...
212 |     fn filter_where(
    |        ^^^^^^^^^^^^

warning: associated function `leap_years_before` is never used
   --> src/result/extended_temporal.rs:108:8
    |
 38 | impl ExtendedDate {
    | ----------------- associated function in this implementation
...
108 |     fn leap_years_before(y: i64) -> i128 {
    |        ^^^^^^^^^^^^^^^^^

warning: `nxcypher` (lib) generated 40 warnings (run `cargo fix --lib -p nxcypher` to apply 25 suggestions)
warning: unused import: `std::convert::Infallible`
 --> tests/tck/main.rs:7:5
  |
7 | use std::convert::Infallible;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: unused import: `Offset`
  --> tests/tck/main.rs:10:92
   |
10 | use chrono::{NaiveDate, NaiveTime, NaiveDateTime, DateTime as ChronoDateTime, FixedOffset, Offset, TimeZone};
   |                                                                                            ^^^^^^

warning: `nxcypher` (test "tck") generated 2 warnings (run `cargo fix --test "tck"` to apply 2 suggestions)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 3.90s
     Running tests/tck/main.rs (target/debug/deps/tck-31502b0d8885e596)
Feature: Call1 - Basic procedure calling
  Scenario: [1] Standalone call to procedure that takes no arguments and yields no results
   ✔  Given an empty graph
   ?  And there exists a procedure test.doNothing() :: ():
       |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:35:5
  Scenario: [2] Standalone call to procedure that takes no arguments and yields no results, called with implicit arguments
   ✔  Given an empty graph
   ?  And there exists a procedure test.doNothing() :: ():
       |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:46:5
  Scenario: [3] In-query call to procedure that takes no arguments and yields no results
   ✔  Given an empty graph
   ?  And there exists a procedure test.doNothing() :: ():
       |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:57:5
  Scenario: [4] In-query call to procedure that takes no arguments and yields no results and consumes no rows
   ✔  Given an empty graph
   ?  And there exists a procedure test.doNothing() :: ():
       |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:71:5
  Scenario: [5] Standalone call to STRING procedure that takes no arguments
   ✔  Given an empty graph
   ?  And there exists a procedure test.labels() :: (label :: STRING?):
       | label |
       | 'A'   |
       | 'B'   |
       | 'C'   |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:94:5
  Scenario: [6] In-query call to STRING procedure that takes no arguments
   ✔  Given an empty graph
   ?  And there exists a procedure test.labels() :: (label :: STRING?):
       | label |
       | 'A'   |
       | 'B'   |
       | 'C'   |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:112:5
  Scenario: [7] Standalone call to procedure should fail if explicit argument is missing
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(name :: STRING?, in :: INTEGER?) :: (out :: INTEGER?):
       | name | in | out |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:131:5
  Scenario: [8] In-query call to procedure should fail if explicit argument is missing
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(name :: STRING?, in :: INTEGER?) :: (out :: INTEGER?):
       | name | in | out |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:141:5
  Scenario: [9] Standalone call to procedure should fail if too many explicit argument are given
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: INTEGER?):
       | in | out |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:152:5
  Scenario: [10] In-query call to procedure should fail if too many explicit argument are given
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: INTEGER?):
       | in | out |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:162:5
  Scenario: [11] Standalone call to procedure should fail if implicit argument is missing
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(name :: STRING?, in :: INTEGER?) :: (out :: INTEGER?):
       | name | in | out |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:173:5
  Scenario: [12] In-query call to procedure that has outputs fails if no outputs are yielded
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: INTEGER?):
       | in | out |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:185:5
  Scenario: [13] Standalone call to unknown procedure should fail
   ✔  Given an empty graph
   ✔  When executing query:
   ?  Then a ProcedureError should be raised at compile time: ProcedureNotFound
      Step skipped: tests/tck/features/clauses/call/Call1.feature:200:5
  Scenario: [14] In-query call to unknown procedure should fail
   ✔  Given an empty graph
   ✔  When executing query:
   ?  Then a ProcedureError should be raised at compile time: ProcedureNotFound
      Step skipped: tests/tck/features/clauses/call/Call1.feature:209:5
  Scenario: [15] In-query procedure call should fail if shadowing an already bound variable
   ✔  Given an empty graph
   ?  And there exists a procedure test.labels() :: (label :: STRING?):
       | label |
       | 'A'   |
       | 'B'   |
       | 'C'   |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:213:5
  Scenario: [16] In-query procedure call should fail if one of the argument expressions uses an aggregation function
   ✔  Given an empty graph
   ?  And there exists a procedure test.labels(in :: INTEGER?) :: (label :: STRING?):
       | in | label |
      Step skipped: tests/tck/features/clauses/call/Call1.feature:228:5
Feature: Call2 - Procedure arguments
  Scenario: [1] In-query call to procedure with explicit arguments
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(name :: STRING?, id :: INTEGER?) :: (city :: STRING?, country_code :: INTEGER?):
       | name     | id | city       | country_code |
       | 'Andres' | 1  | 'Malmö'    | 46           |
       | 'Tobias' | 1  | 'Malmö'    | 46           |
       | 'Mats'   | 1  | 'Malmö'    | 46           |
       | 'Stefan' | 1  | 'Berlin'   | 49           |
       | 'Stefan' | 2  | 'München'  | 49           |
       | 'Petra'  | 1  | 'London'   | 44           |
      Step skipped: tests/tck/features/clauses/call/Call2.feature:35:5
  Scenario: [2] Standalone call to procedure with explicit arguments
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(name :: STRING?, id :: INTEGER?) :: (city :: STRING?, country_code :: INTEGER?):
       | name     | id | city       | country_code |
       | 'Andres' | 1  | 'Malmö'    | 46           |
       | 'Tobias' | 1  | 'Malmö'    | 46           |
       | 'Mats'   | 1  | 'Malmö'    | 46           |
       | 'Stefan' | 1  | 'Berlin'   | 49           |
       | 'Stefan' | 2  | 'München'  | 49           |
       | 'Petra'  | 1  | 'London'   | 44           |
      Step skipped: tests/tck/features/clauses/call/Call2.feature:55:5
  Scenario: [3] Standalone call to procedure with implicit arguments
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(name :: STRING?, id :: INTEGER?) :: (city :: STRING?, country_code :: INTEGER?):
       | name     | id | city       | country_code |
       | 'Andres' | 1  | 'Malmö'    | 46           |
       | 'Tobias' | 1  | 'Malmö'    | 46           |
       | 'Mats'   | 1  | 'Malmö'    | 46           |
       | 'Stefan' | 1  | 'Berlin'   | 49           |
       | 'Stefan' | 2  | 'München'  | 49           |
       | 'Petra'  | 1  | 'London'   | 44           |
      Step skipped: tests/tck/features/clauses/call/Call2.feature:74:5
  Scenario: [4] In-query call to procedure that takes arguments fails when trying to pass them implicitly
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: INTEGER?):
       | in | out |
      Step skipped: tests/tck/features/clauses/call/Call2.feature:97:5
  Scenario: [5] Standalone call to procedure should fail if input type is wrong
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: INTEGER?):
       | in | out |
      Step skipped: tests/tck/features/clauses/call/Call2.feature:108:5
  Scenario: [6] In-query call to procedure should fail if input type is wrong
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: INTEGER?):
       | in | out |
      Step skipped: tests/tck/features/clauses/call/Call2.feature:118:5
Feature: Call3 - Assignable-type arguments
  Scenario: [1] Standalone call to procedure with argument of type NUMBER accepts value of type INTEGER
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: NUMBER?) :: (out :: STRING?):
       | in   | out           |
       | 42   | 'wisdom'      |
       | 42.3 | 'about right' |
      Step skipped: tests/tck/features/clauses/call/Call3.feature:35:5
  Scenario: [2] In-query call to procedure with argument of type NUMBER accepts value of type INTEGER
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: NUMBER?) :: (out :: STRING?):
       | in   | out           |
       | 42   | 'wisdom'      |
       | 42.3 | 'about right' |
      Step skipped: tests/tck/features/clauses/call/Call3.feature:50:5
  Scenario: [3] Standalone call to procedure with argument of type NUMBER accepts value of type FLOAT
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: NUMBER?) :: (out :: STRING?):
       | in   | out           |
       | 42   | 'wisdom'      |
       | 42.3 | 'about right' |
      Step skipped: tests/tck/features/clauses/call/Call3.feature:66:5
  Scenario: [4] In-query call to procedure with argument of type NUMBER accepts value of type FLOAT
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: NUMBER?) :: (out :: STRING?):
       | in   | out           |
       | 42   | 'wisdom'      |
       | 42.3 | 'about right' |
      Step skipped: tests/tck/features/clauses/call/Call3.feature:81:5
  Scenario: [5] Standalone call to procedure with argument of type FLOAT accepts value of type INTEGER
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: FLOAT?) :: (out :: STRING?):
       | in   | out            |
       | 42.0 | 'close enough' |
      Step skipped: tests/tck/features/clauses/call/Call3.feature:97:5
  Scenario: [6] In-query call to procedure with argument of type FLOAT accepts value of type INTEGER
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: FLOAT?) :: (out :: STRING?):
       | in   | out            |
       | 42.0 | 'close enough' |
      Step skipped: tests/tck/features/clauses/call/Call3.feature:111:5
Feature: Call4 - Null Arguments
  Scenario: [1] Standalone call to procedure with null argument
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: STRING?):
       | in   | out   |
       | null | 'nix' |
      Step skipped: tests/tck/features/clauses/call/Call4.feature:35:5
  Scenario: [2] In-query call to procedure with null argument
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: STRING?):
       | in   | out   |
       | null | 'nix' |
      Step skipped: tests/tck/features/clauses/call/Call4.feature:49:5
Feature: Call5 - Results projection
  Scenario: [1] Explicit procedure result projection
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: STRING?):
       | in   | out   |
       | null | 'nix' |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:35:5
  Scenario: [2] Explicit procedure result projection with RETURN *
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: STRING?):
       | in   | out   |
       | null | 'nix' |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:50:5
  Scenario Outline: [3] The order of yield items is irrelevant
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:65:5
  Scenario Outline: [3] The order of yield items is irrelevant
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:65:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario Outline: [4] Rename outputs to unbound variable names
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:85:5
  Scenario: [5] Fail on renaming to an already bound variable name
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:115:5
  Scenario: [6] Fail on renaming all outputs to the same variable name
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (a :: INTEGER?, b :: INTEGER?) :
       | in   | a | b |
       | null | 1 | 2 |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:127:5
  Scenario: [7] Fail on in-query call to procedure with YIELD *
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(name :: STRING?, id :: INTEGER?) :: (city :: STRING?, country_code :: INTEGER?):
       | name     | id | city       | country_code |
       | 'Andres' | 1  | 'Malmö'    | 46           |
       | 'Tobias' | 1  | 'Malmö'    | 46           |
       | 'Mats'   | 1  | 'Malmö'    | 46           |
       | 'Stefan' | 1  | 'Berlin'   | 49           |
       | 'Stefan' | 2  | 'München'  | 49           |
       | 'Petra'  | 1  | 'London'   | 44           |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:140:5
  Scenario: [8] Allow standalone call to procedure with YIELD *
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(name :: STRING?, id :: INTEGER?) :: (city :: STRING?, country_code :: INTEGER?):
       | name     | id | city       | country_code |
       | 'Andres' | 1  | 'Malmö'    | 46           |
       | 'Tobias' | 1  | 'Malmö'    | 46           |
       | 'Mats'   | 1  | 'Malmö'    | 46           |
       | 'Stefan' | 1  | 'Berlin'   | 49           |
       | 'Stefan' | 2  | 'München'  | 49           |
       | 'Petra'  | 1  | 'London'   | 44           |
      Step skipped: tests/tck/features/clauses/call/Call5.feature:157:5
Feature: Call6 - Call clause interoperation with other clauses
  Scenario: [1] Calling the same STRING procedure twice using the same outputs in each call
   ✔  Given an empty graph
   ?  And there exists a procedure test.labels() :: (label :: STRING?):
       | label |
       | 'A'   |
       | 'B'   |
       | 'C'   |
      Step skipped: tests/tck/features/clauses/call/Call6.feature:35:5
  Scenario: [2] Project procedure results between query scopes with WITH clause
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: STRING?):
       | in   | out   |
       | null | 'nix' |
      Step skipped: tests/tck/features/clauses/call/Call6.feature:56:5
  Scenario: [3] Project procedure results between query scopes with WITH clause and rename the projection
   ✔  Given an empty graph
   ?  And there exists a procedure test.my.proc(in :: INTEGER?) :: (out :: STRING?):
       | in   | out   |
       | null | 'nix' |
      Step skipped: tests/tck/features/clauses/call/Call6.feature:71:5
Feature: Create1 - Creating nodes
  Scenario: [1] Create a single node
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes | 1 |
  Scenario: [2] Create two nodes
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes | 2 |
  Scenario: [3] Create a single node with a label
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes  | 1 |
       | +labels | 1 |
  Scenario: [4] Create two nodes with same label
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes  | 2 |
       | +labels | 1 |
  Scenario: [5] Create a single node with multiple labels
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes  | 1 |
       | +labels | 4 |
  Scenario: [6] Create three nodes with multiple labels
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes  | 3 |
       | +labels | 5 |
  Scenario: [7] Create a single node with a property
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
  Scenario: [8] Create a single node with a property and return it
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p     |
       | 'foo' |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
  Scenario: [9] Create a single node with two properties
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 2 |
  Scenario: [10] Create a single node with two properties and return them
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | id | p     |
       | 12 | 'foo' |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 2 |
  Scenario: [11] Create a single node with null properties should not return those properties
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | id | p    |
       | 12 | null |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
  Scenario: [12] CREATE does not lose precision on large integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p.id                |
       | 4611686018427387905 |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
       | +labels     | 1 |
  Scenario: [13] Fail when creating a node that is already bound
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [14] Fail when creating a node with properties that is already bound
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [15] Fail when adding a new label predicate on a node that is already bound 1
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [16] Fail when adding new label predicate on a node that is already bound 2
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [17] Fail when adding new label predicate on a node that is already bound 3
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [18] Fail when adding new label predicate on a node that is already bound 4
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [19] Fail when adding new label predicate on a node that is already bound 5
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [20] Fail when creating a node using undefined variable in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
Feature: Create2 - Creating relationships
  Scenario: [1] Create two nodes and a single relationship in a single pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
  Scenario: [2] Create two nodes and a single relationship in separate patterns
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
  Scenario: [3] Create two nodes and a single relationship in separate clauses
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
  Scenario: [4] Create two nodes and a single relationship in the reverse direction
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +labels        | 2 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | a    | b    |
       | (:A) | (:B) |
  Scenario: [5] Create a single relationship between two existing nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [6] Create a single relationship between two existing nodes in the reverse direction
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | x    | y    |
       | (:X) | (:Y) |
  Scenario: [7] Create a single node and a single self loop in a single pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 1 |
       | +relationships | 1 |
  Scenario: [8] Create a single node and a single self loop in separate patterns
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 1 |
       | +relationships | 1 |
  Scenario: [9] Create a single node and a single self loop in separate clauses
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 1 |
       | +relationships | 1 |
  Scenario: [10] Create a single self loop on an existing node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [11] Create a single relationship and an end node on an existing starting node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 1 |
       | +relationships | 1 |
       | +labels        | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | x        | y      |
       | (:Begin) | (:End) |
  Scenario: [12] Create a single relationship and a starting node on an existing end node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 1 |
       | +relationships | 1 |
       | +labels        | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | x        | y      |
       | (:Begin) | (:End) |
  Scenario: [13] Create a single relationship with a property
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +properties    | 1 |
  Scenario: [14] Create a single relationship with a property and return it
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +properties    | 1 |
  Scenario: [15] Create a single relationship with two properties
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +properties    | 2 |
  Scenario: [16] Create a single relationship with two properties and return them
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | id | name  |
       | 12 | 'foo' |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +properties    | 2 |
  Scenario: [17] Create a single relationship with null properties should not return those properties
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r.id | name |
       | 12   | null |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +properties    | 1 |
  Scenario: [18] Fail when creating a relationship without a type
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NoSingleRelationshipType
  Scenario: [19] Fail when creating a relationship without a direction
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: RequiresDirectedRelationship
  Scenario: [20] Fail when creating a relationship with two directions
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: RequiresDirectedRelationship
  Scenario: [21] Fail when creating a relationship with more than one type
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NoSingleRelationshipType
  Scenario: [22] Fail when creating a variable-length relationship
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: CreatingVarLength
  Scenario: [23] Fail when creating a relationship that is already bound
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [24] Fail when creating a relationship using undefined variable in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
Feature: Create3 - Interoperation with other clauses
  Scenario: [1] MATCH-CREATE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes | 2 |
  Scenario: [2] WITH-CREATE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes | 4 |
  Scenario: [3] MATCH-CREATE-WITH-CREATE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes | 10 |
  Scenario: [4] MATCH-CREATE: Newly-created nodes not visible to preceding MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes | 1 |
  Scenario: [5] WITH-CREATE: Nodes are not created when aliases are applied to variable names
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a          | b          |
       | ({num: 1}) | ({num: 1}) |
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [6] WITH-CREATE: Only a single node is created when an alias is applied to a variable name
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | (:X) |
   ✔  And the side effects should be:
       | +nodes         | 1 |
       | +relationships | 1 |
  Scenario: [7] WITH-CREATE: Nodes are not created when aliases are applied to variable names multiple times
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x             | y             |
       | ({name: 'A'}) | ({name: 'A'}) |
   ✔  And the side effects should be:
       | +relationships | 2 |
  Scenario: [8] WITH-CREATE: Only a single node is created when an alias is applied to a variable name multiple times
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x          |
       | ({num: 5}) |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 2 |
  Scenario: [9] WITH-CREATE: A bound node should be recognized after projection with WITH + WITH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
  Scenario: [10] WITH-UNWIND-CREATE: A bound node should be recognized after projection with WITH + UNWIND
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
  Scenario: [11] WITH-MERGE-CREATE: A bound node should be recognized after projection with WITH + MERGE node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
  Scenario: [12] WITH-MERGE-CREATE: A bound node should be recognized after projection with WITH + MERGE pattern
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 2 |
  Scenario: [13] Merge followed by multiple creates
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +labels        | 2 |
       | +properties    | 1 |
Feature: Create4 - Large Create Query
  Scenario: [1] Generate the movie graph
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 171 |
       | +relationships | 253 |
       | +properties    | 564 |
       | +labels        | 2   |
  Scenario: [2] Many CREATE clauses
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 731  |
       | +relationships | 1247 |
       | +labels        | 6    |
       | +properties    | 230  |
Feature: Create5 - Multiple hops create patterns
  Scenario: [1] Create a pattern with multiple hops
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 3 |
       | +relationships | 2 |
       | +labels        | 3 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | (:A) | (:B) | (:C) |
  Scenario: [2] Create a pattern with multiple hops in the reverse direction
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 3 |
       | +relationships | 2 |
       | +labels        | 3 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | (:A) | (:B) | (:C) |
  Scenario: [3] Create a pattern with multiple hops in varying directions
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 3 |
       | +relationships | 2 |
       | +labels        | 3 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | (:A) | (:B) | (:C) |
  Scenario: [4] Create a pattern with multiple hops with multiple types and varying directions
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 4 |
       | +relationships | 3 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | r1    | r2    | r3    |
       | [:R1] | [:R2] | [:R3] |
  Scenario: [5] Create a pattern with multiple hops and varying directions
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 3 |
       | +relationships | 2 |
       | +labels        | 3 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    | r1    | r2    |
       | (:A) | (:B) | (:C) | [:R1] | [:R2] |
Feature: Create6 - Persistence of create clause side effects
  Scenario: [1] Limiting to zero results after creating nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +labels     | 1 |
       | +properties | 1 |
  Scenario: [2] Skipping all results after creating nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +labels     | 1 |
       | +properties | 1 |
  Scenario: [3] Skipping and limiting to a few results after creating nodes does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | +nodes      | 5 |
       | +labels     | 1 |
       | +properties | 5 |
  Scenario: [4] Skipping zero result and limiting to all results after creating nodes does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | +nodes      | 5 |
       | +labels     | 1 |
       | +properties | 5 |
  Scenario: [5] Filtering after creating nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 2   |
       | 4   |
   ✔  And the side effects should be:
       | +nodes      | 5 |
       | +labels     | 1 |
       | +properties | 5 |
  Scenario: [6] Aggregating in `RETURN` after creating nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | +nodes      | 5 |
       | +labels     | 1 |
       | +properties | 5 |
  Scenario: [7] Aggregating in `WITH` after creating nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | +nodes      | 5 |
       | +labels     | 1 |
       | +properties | 5 |
  Scenario: [8] Limiting to zero results after creating relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +properties    | 1 |
  Scenario: [9] Skipping all results after creating relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +properties    | 1 |
  Scenario: [10] Skipping and limiting to a few results after creating relationships does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | +nodes         | 10 |
       | +relationships | 5  |
       | +properties    | 5  |
  Scenario: [11] Skipping zero result and limiting to all results after creating relationships does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | +nodes         | 10 |
       | +relationships | 5  |
       | +properties    | 5  |
  Scenario: [12] Filtering after creating relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 2   |
       | 4   |
   ✔  And the side effects should be:
       | +nodes         | 10 |
       | +relationships | 5  |
       | +properties    | 5  |
  Scenario: [13] Aggregating in `RETURN` after creating relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | +nodes         | 10 |
       | +relationships | 5  |
       | +properties    | 5  |
  Scenario: [14] Aggregating in `WITH` after creating relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | +nodes         | 10 |
       | +relationships | 5  |
       | +properties    | 5  |
Feature: Delete1 - Deleting nodes
  Scenario: [1] Delete nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -nodes | 1 |
  Scenario: [2] Detach delete node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -nodes | 1 |
  Scenario: [3] Detach deleting connected nodes and relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -nodes         | 1 |
       | -relationships | 3 |
       | -labels        | 1 |
  Scenario: [4] Delete on null node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And no side effects
  Scenario: [5] Ignore null when deleting node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | null |
   ✔  And no side effects
  Scenario: [6] Detach delete on null node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And no side effects
  Scenario: [7] Failing when deleting connected nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a ConstraintVerificationFailed should be raised at runtime: DeleteConnectedNode
      Step skipped: tests/tck/features/clauses/delete/Delete1.feature:130:5
  Scenario: [8] Failing when deleting a label
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidDelete
Feature: Delete2 - Deleting relationships
  Scenario: [1] Delete relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -relationships | 3 |
  Scenario: [2] Delete optionally matched relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -nodes | 1 |
  Scenario: [3] Delete relationship with bidirectional matching
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -relationships | 1 |
       | -properties    | 1 |
  Scenario: [4] Ignore null when deleting relationship
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | null |
   ✔  And no side effects
  Scenario: [5] Failing when deleting a relationship type
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidDelete
Feature: Delete3 - Deleting named paths
  Scenario: [1] Detach deleting paths
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -nodes         | 4 |
       | -relationships | 3 |
       | -labels        | 1 |
  Scenario: [2] Delete on null path
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And no side effects
Feature: Delete4 - Delete clause interoperation with other clauses
  Scenario: [1] Undirected expand followed by delete and count
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c |
       | 2 |
   ✔  And the side effects should be:
       | -nodes         | 2 |
       | -relationships | 1 |
  Scenario: [2] Undirected variable length expand followed by delete and count
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c |
       | 6 |
   ✔  And the side effects should be:
       | -nodes         | 3 |
       | -relationships | 2 |
  Scenario: [3] Create and delete in same query
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✘  And no side effects
      Step failed:
      Defined: tests/tck/features/clauses/delete/Delete4.feature:86:5
      Matched: tests/tck/main.rs:430:1
      Step panicked. Captured output: assertion `left == right` failed: Expected no nodes created
        left: 1
       right: 0
Feature: Delete5 - Delete clause interoperation with built-in data types
  Scenario: [1] Delete node from a list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | friendIndex | 1 |
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -nodes         | 1 |
       | -relationships | 1 |
  Scenario: [2] Delete relationship from a list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | friendIndex | 1 |
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -relationships | 1 |
  Scenario: [3] Delete nodes from a map
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -nodes  | 2 |
       | -labels | 1 |
  Scenario: [4] Delete relationships from a map
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -relationships | 2 |
  Scenario: [5] Detach delete nodes from nested map/list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -nodes         | 1 |
       | -relationships | 2 |
  Scenario: [6] Delete relationships from nested map/list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -relationships | 1 |
  Scenario: [7] Delete paths from nested map/list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | -nodes         | 2 |
       | -relationships | 2 |
       | -labels        | 1 |
  Scenario: [8] Failing when using undefined variable in DELETE
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario: [9] Failing when deleting an integer expression
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Delete6 - Persistence of delete clause side effects
  Scenario: [1] Limiting to zero results after deleting nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
   ✔  And the side effects should be:
       | -nodes      | 1 |
       | -labels     | 1 |
       | -properties | 1 |
  Scenario: [2] Skipping all results after deleting nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
   ✔  And the side effects should be:
       | -nodes      | 1 |
       | -labels     | 1 |
       | -properties | 1 |
  Scenario: [3] Skipping and limiting to a few results after deleting nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | -nodes      | 5 |
       | -labels     | 1 |
       | -properties | 5 |
  Scenario: [4] Skipping zero results and limiting to all results after deleting nodes does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | -nodes      | 5 |
       | -labels     | 1 |
       | -properties | 5 |
  Scenario: [5] Filtering after deleting nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 2   |
       | 4   |
   ✔  And the side effects should be:
       | -nodes      | 5 |
       | -labels     | 1 |
       | -properties | 5 |
  Scenario: [6] Aggregating in `RETURN` after deleting nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | -nodes      | 5 |
       | -labels     | 1 |
       | -properties | 5 |
  Scenario: [7] Aggregating in `WITH` after deleting nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | -nodes      | 5 |
       | -labels     | 1 |
       | -properties | 5 |
  Scenario: [8] Limiting to zero results after deleting relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
   ✔  And the side effects should be:
       | -relationships | 1 |
       | -properties    | 1 |
  Scenario: [9] Skipping all results after deleting relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
   ✔  And the side effects should be:
       | -relationships | 1 |
       | -properties    | 1 |
  Scenario: [10] Skipping and limiting to a few results after deleting relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | -relationships | 5 |
       | -properties    | 5 |
  Scenario: [11] Skipping zero result and limiting to all results after deleting relationships does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | -relationships | 5 |
       | -properties    | 5 |
  Scenario: [12] Filtering after deleting relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 2   |
       | 4   |
   ✔  And the side effects should be:
       | -relationships | 5 |
       | -properties    | 5 |
  Scenario: [13] Aggregating in `RETURN` after deleting relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | -relationships | 5 |
       | -properties    | 5 |
  Scenario: [14] Aggregating in `WITH` after deleting relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | -relationships | 5 |
       | -properties    | 5 |
Feature: Match1 - Match nodes
  Scenario: [1] Match non-existent nodes returns empty
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And no side effects
  Scenario: [2] Matching all nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                |
       | (:A)             |
       | (:B {name: 'b'}) |
       | ({name: 'c'})    |
   ✔  And no side effects
  Scenario: [3] Matching nodes using multiple labels
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a        |
       | (:A:B)   |
       | (:A:B:C) |
   ✔  And no side effects
  Scenario: [4] Simple node inline property predicate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n               |
       | ({name: 'bar'}) |
   ✔  And no side effects
  Scenario: [5] Use multiple MATCH clauses to do a Cartesian product
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n | m |
       | 1 | 1 |
       | 1 | 2 |
       | 1 | 3 |
       | 2 | 1 |
       | 2 | 2 |
       | 2 | 3 |
       | 3 | 3 |
       | 3 | 1 |
       | 3 | 2 |
   ✔  And no side effects
  Scenario: [6] Fail when using parameter as node predicate in MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidParameterUse
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [7] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [8] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when matching a node variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when matching a node variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when matching a node variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when matching a node variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when matching a node variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when matching a node variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when matching a node variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when matching a node variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
Feature: Match2 - Match relationships
  Scenario: [1] Match non-existent relationships returns empty
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r |
   ✔  And no side effects
  Scenario: [2] Matching a relationship pattern using a label predicate on both sides
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r     |
       | [:T1] |
   ✔  And no side effects
  Scenario: [3] Matching a self-loop with an undirected relationship pattern
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r   |
       | 'T' |
   ✔  And no side effects
  Scenario: [4] Matching a self-loop with a directed relationship pattern
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r   |
       | 'T' |
   ✔  And no side effects
  Scenario: [5] Match relationship with inline property value
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | (:A) |
   ✔  And no side effects
  Scenario: [6] Match relationships with multiple types
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r        |
       | [:KNOWS] |
       | [:HATES] |
   ✔  And no side effects
  Scenario: [7] Matching twice with conflicting relationship types on same relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a1 | r | b2 |
   ✔  And no side effects
  Scenario: [8] Fail when using parameter as relationship predicate in MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidParameterUse
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [9] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [10] Fail when a path has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [11] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [12] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [12] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [12] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [12] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [12] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [12] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [12] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [12] Fail when a path has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [13] Fail when matching a relationship variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [13] Fail when matching a relationship variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [13] Fail when matching a relationship variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [13] Fail when matching a relationship variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [13] Fail when matching a relationship variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [13] Fail when matching a relationship variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [13] Fail when matching a relationship variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
  Scenario Outline: [13] Fail when matching a relationship variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
Feature: Match3 - Match fixed length patterns
  Scenario: [1] Get neighbours
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n1            | n2            |
       | (:A {num: 1}) | (:B {num: 2}) |
   ✔  And no side effects
  Scenario: [2] Directed match of a simple relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | r       | b    |
       | (:A) | [:LOOP] | (:B) |
   ✔  And no side effects
  Scenario: [3] Undirected match on simple relationship graph
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | r       | b    |
       | (:A) | [:LOOP] | (:B) |
       | (:B) | [:LOOP] | (:A) |
   ✔  And no side effects
  Scenario: [4] Get two related nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x             |
       | (:B {num: 2}) |
       | (:C {num: 3}) |
   ✔  And no side effects
  Scenario: [5] Return two subgraphs with bound undirected relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a             | b             |
       | (:B {num: 2}) | (:A {num: 1}) |
       | (:A {num: 1}) | (:B {num: 2}) |
   ✔  And no side effects
  Scenario: [6] Matching a relationship pattern using a label predicate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b      |
       | (:Foo) |
   ✔  And no side effects
  Scenario: [7] Matching nodes with many labels
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                            | m              |
       | (:A:B:C:D:E:F:G:H:I:J:K:L:M) | (:Z:Y:X:W:V:U) |
   ✔  And no side effects
  Scenario: [8] Matching using relationship predicate with multiples of the same type
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b    |
       | (:B) |
   ✔  And no side effects
  Scenario: [9] Get related to related to
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b             |
       | (:C {num: 3}) |
   ✔  And no side effects
  Scenario: [10] Matching using self-referencing pattern returns no result
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b |
   ✔  And no side effects
  Scenario: [11] Undirected match in self-relationship graph
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | r       | b    |
       | (:A) | [:LOOP] | (:A) |
   ✔  And no side effects
  Scenario: [12] Undirected match of self-relationship in self-relationship graph
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    | r       |
       | (:A) | [:LOOP] |
   ✔  And no side effects
  Scenario: [13] Directed match on self-relationship graph
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | r       | b    |
       | (:A) | [:LOOP] | (:A) |
   ✔  And no side effects
  Scenario: [14] Directed match of self-relationship on self-relationship graph
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    | r       |
       | (:A) | [:LOOP] |
   ✔  And no side effects
  Scenario: [15] Mixing directed and undirected pattern parts with self-relationship, simple
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x    | r1    | y         | r2      | z         |
       | (:A) | [:T1] | (:Looper) | [:LOOP] | (:Looper) |
       | (:A) | [:T1] | (:Looper) | [:T2]   | (:B)      |
   ✔  And no side effects
  Scenario: [16] Mixing directed and undirected pattern parts with self-relationship, undirected
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x         | r1      | y         | r2      | z         |
       | (:A)      | [:T1]   | (:Looper) | [:LOOP] | (:Looper) |
       | (:A)      | [:T1]   | (:Looper) | [:T2]   | (:B)      |
       | (:Looper) | [:LOOP] | (:Looper) | [:T1]   | (:A)      |
       | (:Looper) | [:LOOP] | (:Looper) | [:T2]   | (:B)      |
       | (:B)      | [:T2]   | (:Looper) | [:LOOP] | (:Looper) |
       | (:B)      | [:T2]   | (:Looper) | [:T1]   | (:A)      |
   ✔  And no side effects
  Scenario: [17] Handling cyclic patterns
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.name |
       | 'a'    |
   ✔  And no side effects
  Scenario: [18] Handling cyclic patterns when separated into two parts
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.name |
       | 'a'    |
   ✔  And no side effects
  Scenario: [19] Two bound nodes pointing to the same node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x              |
       | ({name: 'x1'}) |
       | ({name: 'x2'}) |
   ✔  And no side effects
  Scenario: [20] Three bound nodes pointing to the same node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x              |
       | ({name: 'x1'}) |
       | ({name: 'x2'}) |
   ✔  And no side effects
  Scenario: [21] Three bound nodes pointing to the same node with extra connections
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x             |
       | ({name: 'd'}) |
       | ({name: 'e'}) |
   ✔  And no side effects
  Scenario: [22] Returning bound nodes that are not part of the pattern
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a             | b             | c             |
       | ({name: 'A'}) | ({name: 'B'}) | ({name: 'C'}) |
   ✔  And no side effects
  Scenario: [23] Matching disconnected patterns
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    | d    |
       | (:A) | (:B) | (:A) | (:B) |
       | (:A) | (:B) | (:A) | (:C) |
       | (:A) | (:C) | (:A) | (:B) |
       | (:A) | (:C) | (:A) | (:C) |
   ✔  And no side effects
  Scenario: [24] Matching twice with duplicate relationship types on same relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a1   | r    | b2   |
       | (:A) | [:T] | (:B) |
   ✔  And no side effects
  Scenario: [25] Matching twice with an additional node label
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a1 | r | b2 |
   ✔  And no side effects
  Scenario: [26] Matching twice with a duplicate predicate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a1     | r    | b2 |
       | (:X:Y) | [:T] | () |
   ✔  And no side effects
  Scenario: [27] Matching from null nodes should return no results owing to finding no matches
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b |
   ✔  And no side effects
  Scenario: [28] Matching from null nodes should return no results owing to matches being filtered out
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b |
   ✔  And no side effects
  Scenario: [29] Fail when re-using a relationship in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: RelationshipUniquenessViolation
  Scenario: [30] Fail when using a list or nodes as a node
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableTypeConflict
Feature: Match4 - Match variable length patterns scenarios
  Scenario: [1] Handling fixed-length variable length pattern
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r      |
       | [[:T]] |
   ✔  And no side effects
  Scenario: [2] Simple variable length pattern
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x             |
       | ({name: 'B'}) |
       | ({name: 'C'}) |
       | ({name: 'D'}) |
   ✔  And no side effects
  Scenario: [3] Zero-length variable length pattern in the middle of the pattern
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a             | b             | c             |
       | ({name: 'A'}) | ({name: 'A'}) | ({name: 'A'}) |
       | ({name: 'A'}) | ({name: 'B'}) | ({name: 'B'}) |
       | ({name: 'A'}) | ({name: 'B'}) | ({name: 'C'}) |
   ✔  And no side effects
  Scenario: [4] Matching longer variable length paths
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m              |
       | ({var: 'end'}) |
   ✔  And no side effects
  Scenario: [5] Matching variable length pattern with property predicate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a           | b           |
       | (:Artist:B) | (:Artist:C) |
   ✔  And no side effects
  Scenario: [6] Matching variable length patterns from a bound node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | r            |
       | [[:X], [:Y]] |
      Step skipped: tests/tck/features/clauses/match/Match4.feature:148:5
  Scenario: [7] Matching variable length patterns including a bound relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | c  |
       | 32 |
      Step failed:
      Defined: tests/tck/features/clauses/match/Match4.feature:171:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["c"], values: {"c": Integer(52)} }
  Scenario: [8] Matching relationships into a list and matching variable length using the list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | first | second |
       | (:A)  | (:C)   |
      Step failed:
      Defined: tests/tck/features/clauses/match/Match4.feature:192:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: assertion `left == right` failed: Row count mismatch: expected 1, got 3
        left: 3
       right: 1
  Scenario: [9] Fail when asterisk operator is missing
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidRelationshipPattern
  Scenario: [10] Fail on negative bound
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidRelationshipPattern
Feature: Match5 - Match variable length patterns over given graphs scenarios
  Scenario: [1] Handling unbounded variable length match
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name  |
       | 'n00'   |
       | 'n01'   |
       | 'n000'  |
       | 'n001'  |
       | 'n010'  |
       | 'n011'  |
       | 'n0000' |
       | 'n0001' |
       | 'n0010' |
       | 'n0011' |
       | 'n0100' |
       | 'n0101' |
       | 'n0110' |
       | 'n0111' |
   ✔  And no side effects
  Scenario: [2] Handling explicitly unbounded variable length match
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name  |
       | 'n00'   |
       | 'n01'   |
       | 'n000'  |
       | 'n001'  |
       | 'n010'  |
       | 'n011'  |
       | 'n0000' |
       | 'n0001' |
       | 'n0010' |
       | 'n0011' |
       | 'n0100' |
       | 'n0101' |
       | 'n0110' |
       | 'n0111' |
   ✔  And no side effects
  Scenario: [3] Handling single bounded variable length match 1
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n0'   |
   ✔  And no side effects
  Scenario: [4] Handling single bounded variable length match 2
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n00'  |
       | 'n01'  |
   ✔  And no side effects
  Scenario: [5] Handling single bounded variable length match 3
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n000' |
       | 'n001' |
       | 'n010' |
       | 'n011' |
   ✔  And no side effects
  Scenario: [6] Handling upper and lower bounded variable length match 1
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n0'   |
       | 'n00'  |
       | 'n01'  |
       | 'n000' |
       | 'n001' |
       | 'n010' |
       | 'n011' |
   ✔  And no side effects
  Scenario: [7] Handling upper and lower bounded variable length match 2
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n00'  |
       | 'n01'  |
       | 'n000' |
       | 'n001' |
       | 'n010' |
       | 'n011' |
   ✔  And no side effects
  Scenario: [8] Handling symmetrically bounded variable length match, bounds are zero
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n0'   |
   ✔  And no side effects
  Scenario: [9] Handling symmetrically bounded variable length match, bounds are one
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n00'  |
       | 'n01'  |
   ✔  And no side effects
  Scenario: [10] Handling symmetrically bounded variable length match, bounds are two
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n000' |
       | 'n001' |
       | 'n010' |
       | 'n011' |
   ✔  And no side effects
  Scenario: [11] Handling upper and lower bounded variable length match, empty interval 1
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
   ✔  And no side effects
  Scenario: [12] Handling upper and lower bounded variable length match, empty interval 2
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
   ✔  And no side effects
  Scenario: [13] Handling upper bounded variable length match, empty interval
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
   ✔  And no side effects
  Scenario: [14] Handling upper bounded variable length match 1
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n00'  |
       | 'n01'  |
   ✔  And no side effects
  Scenario: [15] Handling upper bounded variable length match 2
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n00'  |
       | 'n01'  |
       | 'n000' |
       | 'n001' |
       | 'n010' |
       | 'n011' |
   ✔  And no side effects
  Scenario: [16] Handling lower bounded variable length match 1
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name  |
       | 'n0'    |
       | 'n00'   |
       | 'n01'   |
       | 'n000'  |
       | 'n001'  |
       | 'n010'  |
       | 'n011'  |
       | 'n0000' |
       | 'n0001' |
       | 'n0010' |
       | 'n0011' |
       | 'n0100' |
       | 'n0101' |
       | 'n0110' |
       | 'n0111' |
   ✔  And no side effects
  Scenario: [17] Handling lower bounded variable length match 2
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name  |
       | 'n00'   |
       | 'n01'   |
       | 'n000'  |
       | 'n001'  |
       | 'n010'  |
       | 'n011'  |
       | 'n0000' |
       | 'n0001' |
       | 'n0010' |
       | 'n0011' |
       | 'n0100' |
       | 'n0101' |
       | 'n0110' |
       | 'n0111' |
   ✔  And no side effects
  Scenario: [18] Handling lower bounded variable length match 3
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name  |
       | 'n000'  |
       | 'n001'  |
       | 'n010'  |
       | 'n011'  |
       | 'n0000' |
       | 'n0001' |
       | 'n0010' |
       | 'n0011' |
       | 'n0100' |
       | 'n0101' |
       | 'n0110' |
       | 'n0111' |
   ✔  And no side effects
  Scenario: [19] Handling a variable length relationship and a standard relationship in chain, zero length 1
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n00'  |
       | 'n01'  |
   ✔  And no side effects
  Scenario: [20] Handling a variable length relationship and a standard relationship in chain, zero length 2
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n00'  |
       | 'n01'  |
   ✔  And no side effects
  Scenario: [21] Handling a variable length relationship and a standard relationship in chain, single length 1
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n000' |
       | 'n001' |
       | 'n010' |
       | 'n011' |
   ✔  And no side effects
  Scenario: [22] Handling a variable length relationship and a standard relationship in chain, single length 2
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'n000' |
       | 'n001' |
       | 'n010' |
       | 'n011' |
   ✔  And no side effects
  Scenario: [23] Handling a variable length relationship and a standard relationship in chain, longer 1
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name  |
       | 'n0000' |
       | 'n0001' |
       | 'n0010' |
       | 'n0011' |
       | 'n0100' |
       | 'n0101' |
       | 'n0110' |
       | 'n0111' |
   ✔  And no side effects
  Scenario: [24] Handling a variable length relationship and a standard relationship in chain, longer 2
   ✔  Given the variable-length-test-graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name  |
       | 'n0000' |
       | 'n0001' |
       | 'n0010' |
       | 'n0011' |
       | 'n0100' |
       | 'n0101' |
       | 'n0110' |
       | 'n0111' |
   ✔  And no side effects
  Scenario: [25] Handling a variable length relationship and a standard relationship in chain, longer 3
   ✔  Given the variable-length-test-graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name   |
       | 'n00000' |
       | 'n00001' |
       | 'n00010' |
       | 'n00011' |
       | 'n00100' |
       | 'n00101' |
       | 'n00110' |
       | 'n00111' |
       | 'n01000' |
       | 'n01001' |
       | 'n01010' |
       | 'n01011' |
       | 'n01100' |
       | 'n01101' |
       | 'n01110' |
       | 'n01111' |
   ✔  And no side effects
  Scenario: [26] Handling mixed relationship patterns and directions 1
   ✔  Given the variable-length-test-graph
   ✔  And having executed:
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name   |
       | 'n00000' |
       | 'n00001' |
       | 'n00010' |
       | 'n00011' |
       | 'n00100' |
       | 'n00101' |
       | 'n00110' |
       | 'n00111' |
       | 'n01000' |
       | 'n01001' |
       | 'n01010' |
       | 'n01011' |
       | 'n01100' |
       | 'n01101' |
       | 'n01110' |
       | 'n01111' |
   ✔  And no side effects
  Scenario: [27] Handling mixed relationship patterns and directions 2
   ✔  Given the variable-length-test-graph
   ✔  And having executed:
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | c.name   |
       | 'n00000' |
       | 'n00001' |
       | 'n00010' |
       | 'n00011' |
       | 'n00100' |
       | 'n00101' |
       | 'n00110' |
       | 'n00111' |
       | 'n01000' |
       | 'n01001' |
       | 'n01010' |
       | 'n01011' |
       | 'n01100' |
       | 'n01101' |
       | 'n01110' |
       | 'n01111' |
      Step failed:
      Defined: tests/tck/features/clauses/match/Match5.feature:555:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: assertion `left == right` failed: Row count mismatch: expected 16, got 20
        left: 20
       right: 16
  Scenario: [28] Handling mixed relationship patterns 1
   ✔  Given the variable-length-test-graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name   |
       | 'n00000' |
       | 'n00001' |
       | 'n00010' |
       | 'n00011' |
       | 'n00100' |
       | 'n00101' |
       | 'n00110' |
       | 'n00111' |
       | 'n01000' |
       | 'n01001' |
       | 'n01010' |
       | 'n01011' |
       | 'n01100' |
       | 'n01101' |
       | 'n01110' |
       | 'n01111' |
   ✔  And no side effects
  Scenario: [29] Handling mixed relationship patterns 2
   ✔  Given the variable-length-test-graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name   |
       | 'n00000' |
       | 'n00001' |
       | 'n00010' |
       | 'n00011' |
       | 'n00100' |
       | 'n00101' |
       | 'n00110' |
       | 'n00111' |
       | 'n01000' |
       | 'n01001' |
       | 'n01010' |
       | 'n01011' |
       | 'n01100' |
       | 'n01101' |
       | 'n01110' |
       | 'n01111' |
   ✔  And no side effects
Feature: Match6 - Match named paths scenarios
  Scenario: [1] Zero-length named path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | <()> |
   ✔  And no side effects
  Scenario: [2] Return a simple path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                                             |
       | <(:A {name: 'A'})-[:KNOWS]->(:B {name: 'B'})> |
   ✔  And no side effects
  Scenario: [3] Return a three node path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                                                                        |
       | <(:A {name: 'A'})-[:KNOWS]->(:B {name: 'B'})-[:KNOWS]->(:C {name: 'C'})> |
   ✔  And no side effects
  Scenario: [4] Respecting direction when matching non-existent path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p |
   ✔  And no side effects
  Scenario: [5] Path query should return results in written order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                              |
       | <(:Label1)<-[:TYPE]-(:Label2)> |
   ✔  And no side effects
  Scenario: [6] Handling direction of named paths
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                 |
       | <(:B)<-[:T]-(:A)> |
   ✔  And no side effects
  Scenario: [7] Respecting direction when matching existing path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                                   |
       | <({name: 'a'})-[:T]->({name: 'b'})> |
   ✔  And no side effects
  Scenario: [8] Respecting direction when matching non-existent path with multiple directions
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p |
   ✔  And no side effects
  Scenario: [9] Longer path query should return results in written order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                                             |
       | <(:Label1)<-[:T1]-(:Label2)-[:T2]->(:Label3)> |
   ✔  And no side effects
  Scenario: [10] Named path with alternating directed/undirected relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                            |
       | <(:C)-[:T]->(:B)-[:T]->(:A)> |
   ✔  And no side effects
  Scenario: [11] Named path with multiple alternating directed/undirected relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | path                                    |
       | <(:D)-[:T]->(:C)-[:T]->(:B)-[:T]->(:A)> |
   ✔  And no side effects
  Scenario: [12] Matching path with multiple bidirectional relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                              |
       | <(:A)<-[:T2]-(:B)<-[:T1]-(:A)> |
       | <(:A)-[:T1]->(:B)-[:T2]->(:A)> |
       | <(:B)<-[:T1]-(:A)<-[:T2]-(:B)> |
       | <(:B)-[:T2]->(:A)-[:T1]->(:B)> |
   ✔  And no side effects
  Scenario: [13] Matching path with both directions should respect other directions
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                              |
       | <(:A)<-[:T2]-(:B)<-[:T1]-(:A)> |
       | <(:B)<-[:T1]-(:A)<-[:T2]-(:B)> |
   ✔  And no side effects
  Scenario: [14] Named path with undirected fixed variable length pattern
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | topRoute                                                                                       |
       | <(:Start)<-[:CONNECTED_TO]-()-[:CONNECTED_TO]->()<-[:CONNECTED_TO]-()-[:CONNECTED_TO]->(:End)> |
       | <(:Start)<-[:CONNECTED_TO]-()-[:CONNECTED_TO]->()<-[:CONNECTED_TO]-()-[:CONNECTED_TO]->(:End)> |
       | <(:Start)<-[:CONNECTED_TO]-()-[:CONNECTED_TO]->()<-[:CONNECTED_TO]-()-[:CONNECTED_TO]->(:End)> |
       | <(:Start)<-[:CONNECTED_TO]-()-[:CONNECTED_TO]->()<-[:CONNECTED_TO]-()-[:CONNECTED_TO]->(:End)> |
      Step failed:
      Defined: tests/tck/features/clauses/match/Match6.feature:273:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: assertion `left == right` failed: Row count mismatch: expected 4, got 2
        left: 2
       right: 4
  Scenario: [15] Variable-length named path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | <()> |
   ✔  And no side effects
  Scenario: [16] Return a var length path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                                                                                          |
       | <(:A {name: 'A'})-[:KNOWS {num: 1}]->(:B {name: 'B'})>                                     |
       | <(:A {name: 'A'})-[:KNOWS {num: 1}]->(:B {name: 'B'})-[:KNOWS {num: 2}]->(:C {name: 'C'})> |
   ✔  And no side effects
  Scenario: [17] Return a named var length path of length zero
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                                                                         |
       | <(:A {name: 'A'})>                                                        |
       | <(:A {name: 'A'})-[:KNOWS]->(:B {name: 'B'})>                             |
       | <(:A {name: 'A'})-[:KNOWS]->(:B {name: 'B'})-[:FRIEND]->(:C {name: 'C'})> |
   ✔  And no side effects
  Scenario: [18] Undirected named path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                   |
       | <(:Movie)<-[:T]-()> |
   ✔  And no side effects
  Scenario: [19] Variable length relationship without lower bound
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                                                               |
       | <({name: 'A'})-[:KNOWS]->({name: 'B'})>                         |
       | <({name: 'A'})-[:KNOWS]->({name: 'B'})-[:KNOWS]->({name: 'C'})> |
   ✔  And no side effects
  Scenario: [20] Variable length relationship without bounds
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                                                               |
       | <({name: 'A'})-[:KNOWS]->({name: 'B'})>                         |
       | <({name: 'A'})-[:KNOWS]->({name: 'B'})-[:KNOWS]->({name: 'C'})> |
   ✔  And no side effects
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [21] Fail when a node has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [22] Fail when a relationship has the same variable in a preceding MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [23] Fail when a node has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [24] Fail when a relationship has the same variable in the same pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [25] Fail when matching a path variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [25] Fail when matching a path variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [25] Fail when matching a path variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [25] Fail when matching a path variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [25] Fail when matching a path variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [25] Fail when matching a path variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [25] Fail when matching a path variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario Outline: [25] Fail when matching a path variable bound to a value
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
Feature: Match7 - Optional match
  Scenario: [1] Simple OPTIONAL MATCH on empty graph
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | null |
   ✔  And no side effects
  Scenario: [2] OPTIONAL MATCH with previously bound nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n  | x    |
       | () | null |
   ✔  And no side effects
  Scenario: [3] OPTIONAL MATCH and bound nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x              |
       | (:A {num: 42}) |
   ✔  And no side effects
  Scenario: [4] Optionally matching relationship with bound nodes in reverse direction
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a1   | r    | b2   |
       | (:A) | [:T] | null |
   ✔  And no side effects
  Scenario: [5] Optionally matching relationship with a relationship that is already bound
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a2   | r    | b2   |
       | (:A) | [:T] | (:B) |
   ✔  And no side effects
  Scenario: [6] Optionally matching relationship with a relationship and node that are both already bound
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a1   | r    | b2   |
       | (:A) | [:T] | (:B) |
   ✔  And no side effects
  Scenario: [7] MATCH with OPTIONAL MATCH in longer pattern
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | foo           |
       | ({name: 'C'}) |
   ✔  And no side effects
  Scenario: [8] Longer pattern with bound nodes without matches
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b    |
       | null |
   ✔  And no side effects
  Scenario: [9] Longer pattern with bound nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b              |
       | (:A {num: 42}) |
   ✔  And no side effects
  Scenario: [10] Optionally matching from null nodes should return null
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b    |
       | null |
   ✔  And no side effects
  Scenario: [11] Return two subgraphs with bound undirected relationship and optional relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a             | b             | c             |
       | (:A {num: 1}) | (:B {num: 2}) | (:C {num: 3}) |
       | (:B {num: 2}) | (:A {num: 1}) | null          |
   ✔  And no side effects
  Scenario: [12] Variable length optional relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b              |
       | (:A {num: 42}) |
       | (:B {num: 46}) |
       | (:B {num: 46}) |
       | (:C)           |
   ✔  And no side effects
  Scenario: [13] Variable length optional relationships with bound nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x    |
       | (:C) |
   ✔  And no side effects
  Scenario: [14] Variable length optional relationships with length predicates
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b    |
       | null |
   ✔  And no side effects
  Scenario: [15] Variable length patterns and nulls
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | (:A) | null | null |
   ✔  And no side effects
  Scenario: [16] Optionally matching named paths - null result
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | null |
   ✔  And no side effects
  Scenario: [17] Optionally matching named paths - existing result
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x             | p                                   |
       | ({name: 'B'}) | <({name: 'A'})-[:X]->({name: 'B'})> |
       | ({name: 'C'}) | null                                |
   ✔  And no side effects
  Scenario: [18] Named paths inside optional matches with node predicates
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | null |
   ✔  And no side effects
  Scenario: [19] Optionally matching named paths with single and variable length patterns
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | null |
   ✔  And no side effects
  Scenario: [20] Variable length optional relationships with bound nodes, no matches
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | null |
   ✔  And no side effects
  Scenario: [21] Handling optional matches between nulls
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | r    |
       | null | null | null |
   ✔  And no side effects
  Scenario: [22] MATCH after OPTIONAL MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d |
   ✔  And no side effects
  Scenario: [23] OPTIONAL MATCH with labels on the optional end node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b      |
       | null   |
       | (:Y)   |
       | (:Y:Z) |
   ✔  And no side effects
  Scenario: [24] Optionally matching self-loops
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r       |
       | [:LOOP] |
   ✔  And no side effects
  Scenario: [25] Optionally matching self-loops without matches
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | null |
       | null |
       | null |
   ✔  And no side effects
  Scenario: [26] Handling correlated optional matches; first does not match implies second does not match
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x    | r    |
       | (:C) | null |
   ✔  And no side effects
  Scenario: [27] Handling optional matches between optionally matched entities
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b              | r    |
       | null | (:B {num: 46}) | null |
   ✔  And no side effects
  Scenario: [28] Handling optional matches with inline label predicate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | null |
   ✔  And no side effects
  Scenario: [29] Satisfies the open world assumption, relationships between same nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | matches | optMatch |
       | 1       | false    |
   ✔  And no side effects
  Scenario: [30] Satisfies the open world assumption, single relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | matches | optMatch |
       | 1       | true     |
   ✔  And no side effects
  Scenario: [31] Satisfies the open world assumption, relationships between different nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | matches | optMatch |
       | 1       | true     |
   ✔  And no side effects
Feature: Match8 - Match clause interoperation with other clauses
  Scenario: [1] Pattern independent of bound variables results in cross product
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    |
       | (:A) | (:A) |
       | (:A) | (:B) |
       | (:B) | (:A) |
       | (:B) | (:B) |
   ✔  And no side effects
  Scenario: [2] Counting rows after MATCH, MERGE, OPTIONAL MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 6        |
   ✔  And no side effects
  Scenario: [3] Matching and disregarding output, then matching again
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum(r1.times) |
       | 776           |
   ✔  And no side effects
Feature: Match9 - Match deprecated scenarios
  Scenario: [1] Variable length relationship variables are lists of relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | l    |
       | [:T] |
       | [:T] |
       | null |
       | null |
       | null |
   ✔  And no side effects
  Scenario: [2] Return relationships by collecting them as a list - directed, one way
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r                                  |
       | [[:REL {num: 1}], [:REL {num: 2}]] |
   ✔  And no side effects
  Scenario: [3] Return relationships by collecting them as a list - undirected, starting from two extremes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r                                |
       | [[:REL {num:1}], [:REL {num:2}]] |
       | [[:REL {num:2}], [:REL {num:1}]] |
   ✔  And no side effects
  Scenario: [4] Return relationships by collecting them as a list - undirected, starting from one extreme
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r                                  |
       | [[:REL {num: 1}], [:REL {num: 2}]] |
   ✔  And no side effects
  Scenario: [5] Variable length pattern with label predicate on both sides
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And no side effects
  Scenario: [6] Matching relationships into a list and matching variable length using the list, with bound nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | first | second |
       | (:A)  | (:C)   |
   ✔  And no side effects
  Scenario: [7] Matching relationships into a list and matching variable length using the list, with bound nodes, wrong direction
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | first | second |
   ✔  And no side effects
  Scenario: [8] Variable length relationship in OPTIONAL MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b    |
       | (:B) |
   ✔  And no side effects
  Scenario: [9] Optionally matching named paths with variable length patterns
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r      | x             | p                                   |
       | [[:X]] | ({name: 'B'}) | <({name: 'A'})-[:X]->({name: 'B'})> |
       | null   | ({name: 'C'}) | null                                |
   ✔  And no side effects
Feature: MatchWhere1 - Filter single variable
  Scenario: [1] Filter node with node label predicate on multi variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.id | b.id |
       | 0    | 1    |
   ✔  And no side effects
  Scenario: [2] Filter node with node label predicate on multi variables without any bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c |
   ✔  And no side effects
  Scenario: [3] Filter node with property predicate on a single variable with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n               |
       | ({name: 'Bar'}) |
   ✔  And no side effects
  Scenario: [4] Filter start node of relationship with property predicate on multi variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                       |
       | (:Person {name: 'Bob'}) |
   ✔  And no side effects
  Scenario: [5] Filter end node of relationship with property predicate on multi variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                  |
       | ({name: 'Andres'}) |
   ✔  And no side effects
  Scenario: [6] Filter node with a parameter in a property predicate on multi variables with one binding
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | param | 'me' |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r                  |
       | [:T {name: 'bar'}] |
   ✔  And no side effects
  Scenario: [7] Filter relationship with relationship type predicate on multi variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x                |
       | (:B {name: 'B'}) |
   ✔  And no side effects
  Scenario: [8] Filter relationship with property predicate on multi variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | (:A) |
   ✔  And no side effects
  Scenario: [9] Filter relationship with a parameter in a property predicate on multi variables with one binding
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | param | 'bar' |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b                 |
       | (:B {name: 'me'}) |
   ✔  And no side effects
  Scenario: [10] Filter node with disjunctive property predicate on single variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n             |
       | (:A {p1: 12}) |
       | (:B {p2: 13}) |
   ✔  And no side effects
  Scenario: [11] Filter relationship with disjunctive relationship type predicate on multi variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r        |
       | [:KNOWS] |
       | [:HATES] |
   ✔  And no side effects
  Scenario: [12] Filter path with path length predicate on multi variables with one binding
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x                |
       | (:B {name: 'B'}) |
   ✔  And no side effects
  Scenario: [13] Filter path with false path length predicate on multi variables with one binding
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
   ✔  And no side effects
  Scenario: [14] Fail when filtering path with property predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario: [15] Fail on aggregation in WHERE
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
Feature: MatchWhere2 - Filter multiple variables
  Scenario: [1] Filter nodes with conjunctive two-part property predicate on multi variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d    |
       | (:A) |
       | (:D) |
   ✔  And no side effects
  Scenario: [2] Filter node with conjunctive multi-part property predicates on multi variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | 1 | 0 |
       | 2 | 1 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | out.name   |
       | 'product1' |
   ✔  And no side effects
Feature: MatchWhere3 - Equi-Joins on variables
  Scenario: [1] Join between node identities
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    |
       | (:A) | (:A) |
       | (:B) | (:B) |
   ✔  And no side effects
  Scenario: [2] Join between node properties of disconnected nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a            | b            |
       | (:A {id: 2}) | (:B {id: 2}) |
   ✔  And no side effects
  Scenario: [3] Join between node properties of adjacent nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                       | x                       |
       | (:A {animal: 'monkey'}) | (:C {animal: 'monkey'}) |
       | (:D {animal: 'cow'})    | (:B {animal: 'cow'})    |
   ✔  And no side effects
Feature: MatchWhere4 - Non-Equi-Joins on variables
  Scenario: [1] Join nodes on inequality
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    |
       | (:A) | (:B) |
       | (:B) | (:A) |
   ✔  And no side effects
  Scenario: [2] Join with disjunctive multi-part predicates including patterns
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b                   |
       | (:TheLabel {id: 1}) |
   ✔  And no side effects
Feature: MatchWhere5 - Filter on predicate resulting in null
  Scenario: [1] Filter out on null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i                         |
       | (:TextNode {var: 'text'}) |
   ✔  And no side effects
  Scenario: [2] Filter out on null if the AND'd predicate evaluates to false
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i                         |
       | (:TextNode {var: 'text'}) |
   ✔  And no side effects
  Scenario: [3] Filter out on null if the AND'd predicate evaluates to true
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i                         |
       | (:TextNode {var: 'text'}) |
   ✔  And no side effects
  Scenario: [4] Do not filter out on null if the OR'd predicate evaluates to true
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i                         |
       | (:TextNode {var: 'text'}) |
       | (:IntNode {var: 0})       |
   ✔  And no side effects
Feature: MatchWhere6 - Filter optional matches
  Scenario: [1] Filter node with node label predicate on multi variables with multiple bindings after MATCH and OPTIONAL MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.name |
       | 'A'    |
   ✔  And no side effects
  Scenario: [2] Filter node with false node label predicate after OPTIONAL MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | null |
   ✔  And no side effects
  Scenario: [3] Filter node with property predicate on multi variables with multiple bindings after OPTIONAL MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m              |
       | (:A {num: 42}) |
   ✔  And no side effects
  Scenario: [4] Do not fail when predicates on optionally matched and missed nodes are invalid
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x0.name |
       | 'Mark'  |
   ✔  And no side effects
  Scenario: [5] Matching and optionally matching with unbound nodes and equality predicate in reverse direction
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a1   | r    | b2   | a2   |
       | (:A) | [:T] | null | null |
   ✔  And no side effects
  Scenario: [6] Join nodes on non-equality of properties – OPTIONAL MATCH and WHERE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x             | y             |
       | (:X {val: 1}) | (:Y {val: 2}) |
       | (:X {val: 4}) | (:Y {val: 5}) |
       | (:X {val: 6}) | null          |
   ✔  And no side effects
  Scenario: [7] Join nodes on non-equality of properties – OPTIONAL MATCH on two relationships and WHERE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x             | y             | z             |
       | (:X {val: 1}) | (:Y {val: 2}) | (:Z {val: 3}) |
       | (:X {val: 4}) | null          | null          |
       | (:X {val: 6}) | null          | null          |
   ✔  And no side effects
  Scenario: [8] Join nodes on non-equality of properties – Two OPTIONAL MATCH clauses and WHERE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x             | y             | z             |
       | (:X {val: 1}) | (:Y {val: 2}) | (:Z {val: 3}) |
       | (:X {val: 4}) | (:Y {val: 5}) | null          |
       | (:X {val: 6}) | null          | null          |
   ✔  And no side effects
Feature: Merge1 - Merge node
  Scenario: [1] Merge node when no nodes exist
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
       | 1 |
   ✔  And the side effects should be:
       | +nodes | 1 |
  Scenario: [2] Merge node with label
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | labels(a)    |
       | ['TheLabel'] |
   ✔  And the side effects should be:
       | +nodes  | 1 |
       | +labels | 1 |
  Scenario: [3] Merge node with label when it exists
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.id |
       | 1    |
   ✔  And no side effects
  Scenario: [4] Merge node should create when it doesn't match, properties
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.num |
       | 43    |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
  Scenario: [5] Merge node should create when it doesn't match, properties and label
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.num |
       | 43    |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
  Scenario: [6] Merge node with prop and label
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.num |
       | 42    |
   ✔  And no side effects
  Scenario: [7] Merge should work when finding multiple elements
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes  | 2 |
       | +labels | 1 |
  Scenario: [8] Merge should handle argument properly
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +labels     | 1 |
       | +properties | 1 |
  Scenario: [9] Merge should support updates while merging
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x | y |
       | 0 | 0 |
       | 0 | 1 |
       | 0 | 2 |
       | 1 | 0 |
       | 1 | 1 |
       | 1 | 2 |
       | 2 | 0 |
       | 2 | 1 |
       | 2 | 2 |
   ✔  And the side effects should be:
       | +nodes      | 15 |
       | +labels     | 1  |
       | +properties | 30 |
  Scenario: [10] Merge must properly handle multiple labels
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | labels     |
       | ['L', 'B'] |
      Step skipped: tests/tck/features/clauses/merge/Merge1.feature:203:5
  Scenario: [11] Merge should be able to merge using property of bound node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 3 |
       | +labels     | 1 |
       | +properties | 3 |
  Scenario: [12] Merge should be able to merge using property of freshly created node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 2 |
       | +properties | 2 |
  Scenario: [13] Merge should bind a path
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p            |
       | <({num: 1})> |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
  Scenario: [14] Merges should not be able to match on deleted nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a2.num |
       | null   |
       | null   |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | -nodes      | 2 |
       | -properties | 2 |
  Scenario: [15] Fail when merge a node that is already bound
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [16] Fail when using parameter as node predicate in MERGE
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidParameterUse
  Scenario: [17] Fail on merging node with null property
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a SemanticError should be raised at runtime: MergeReadOwnWrites
      Step skipped: tests/tck/features/clauses/merge/Merge1.feature:306:5
Feature: Merge2 - Merge node - on create
  Scenario: [1] Merge node with label add label on create
   ✔  Given an empty graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | labels(a)           |
       | ['TheLabel', 'Foo'] |
      Step skipped: tests/tck/features/clauses/merge/Merge2.feature:41:5
  Scenario: [2] ON CREATE on created nodes
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
  Scenario: [3] Merge node with label add property on create
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.num |
       | 42    |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +labels     | 1 |
       | +properties | 1 |
  Scenario: [4] Merge node with label add property on update when it exists
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.num |
       | null  |
   ✔  And no side effects
  Scenario: [5] Merge should be able to use properties of bound node in ON CREATE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | person.bornIn |
       | 'New York'    |
       | 'Ohio'        |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +labels     | 1 |
       | +properties | 1 |
  Scenario: [6] Fail when using undefined variable in ON CREATE
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
Feature: Merge3 - Merge node - on match
  Scenario: [1] Merge should be able to set labels on match
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [2] Merge node with label add label on match when it exists
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | labels(a)           |
       | ['TheLabel', 'Foo'] |
      Step skipped: tests/tck/features/clauses/merge/Merge3.feature:60:5
  Scenario: [3] Merge node and set property on match
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.num |
       | 42    |
   ✔  And the side effects should be:
       | +properties | 1 |
  Scenario: [4] Merge should be able to use properties of bound node in ON MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | person.bornIn |
       | 'New York'    |
       | 'Ohio'        |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +labels     | 1 |
       | +properties | 1 |
  Scenario: [5] Fail when using undefined variable in ON MATCH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
Feature: Merge4 - Merge node - on match and on create
  Scenario: [1] Merge should be able to set labels on match and on create
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes  | 1 |
       | +labels | 3 |
  Scenario: [2] Merge should be able to use properties of bound node in ON MATCH and ON CREATE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | person.bornIn |
       | 'New York'    |
       | 'Ohio'        |
   ✘  And the side effects should be:
       | +nodes      | 1 |
       | +labels     | 1 |
       | +properties | 1 |
      Step failed:
      Defined: tests/tck/features/clauses/merge/Merge4.feature:70:5
      Matched: tests/tck/main.rs:444:1
      Step panicked. Captured output: assertion `left == right` failed: properties_set mismatch
        left: 2
       right: 1
Feature: Merge5 - Merge relationships
  Scenario: [1] Creating a relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [2] Matching a relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And no side effects
  Scenario: [3] Matching two relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 2        |
   ✔  And no side effects
  Scenario: [4] Using bound variables from other updating clause
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(a) |
       | 1        |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
  Scenario: [5] Filtering relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And no side effects
  Scenario: [6] Creating relationship when all matches filtered out
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And the side effects should be:
       | +relationships | 1 |
       | +properties    | 1 |
  Scenario: [7] Matching incoming relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And no side effects
  Scenario: [8] Creating relationship with property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And the side effects should be:
       | +relationships | 1 |
       | +properties    | 1 |
  Scenario: [9] Creating relationship using merged nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [10] Merge should bind a path
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p                             |
       | <({num: 1})-[:R]->({num: 2})> |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +properties    | 2 |
  Scenario: [11] Use outgoing direction when unspecified
   ✔  Given an empty graph
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | s | e |
       | 2 | 1 |
      Step failed:
      Defined: tests/tck/features/clauses/merge/Merge5.feature:221:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["s", "e"], values: {"s": Null, "e": Null} }
  Scenario: [12] Match outgoing relationship when direction unspecified
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r        |
       | [:KNOWS] |
   ✔  And no side effects
  Scenario: [13] Match both incoming and outgoing relationships when direction unspecified
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r                     |
       | [:KNOWS {name: 'ab'}] |
       | [:KNOWS {name: 'cd'}] |
   ✔  And no side effects
  Scenario: [14] Using list properties via variable
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 2        |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +labels        | 2 |
       | +properties    | 1 |
  Scenario: [15] Matching using list property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And no side effects
  Scenario: [16] Aliasing of existing nodes 1
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b |
       | 0 | 0 |
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [17] Aliasing of existing nodes 2
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 0 |
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [18] Double aliasing of existing nodes 1
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x | y |
       | 0 | 0 |
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [19] Double aliasing of existing nodes 2
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 0 |
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [20] Do not match on deleted entities
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | -nodes         | 4 |
       | +relationships | 2 |
       | -relationships | 4 |
       | +properties    | 1 |
       | -properties    | 2 |
  Scenario: [21] Do not match on deleted relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t2.name |
       | 'rel3'  |
       | 'rel3'  |
   ✔  And the side effects should be:
       | +relationships | 1 |
       | -relationships | 2 |
       | +properties    | 1 |
       | -properties    | 2 |
  Scenario: [22] Fail when imposing new predicates on a variable that is already bound
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [23] Fail when merging relationship without type
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NoSingleRelationshipType
  Scenario: [24] Fail when merging relationship without type, no colon
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NoSingleRelationshipType
  Scenario: [25] Fail when merging relationship with more than one type
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NoSingleRelationshipType
  Scenario: [26] Fail when merging relationship that is already bound
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: VariableAlreadyBound
  Scenario: [27] Fail when using parameter as relationship predicate in MERGE
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidParameterUse
  Scenario: [28] Fail when using variable length relationship in MERGE
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: CreatingVarLength
  Scenario: [29] Fail on merging relationship with null property
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a SemanticError should be raised at runtime: MergeReadOwnWrites
      Step skipped: tests/tck/features/clauses/merge/Merge5.feature:519:5
Feature: Merge6 - Merge relationships - on create
  Scenario: [1] Using ON CREATE on a node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
       | +properties    | 1 |
  Scenario: [2] Using ON CREATE on a relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And the side effects should be:
       | +relationships | 1 |
       | +properties    | 1 |
  Scenario: [3] Updating one property with ON CREATE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
       | +properties    | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | keyValue      |
       | ['name->foo'] |
  Scenario: [4] Null-setting one property with ON CREATE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | keyValue |
       | []       |
  Scenario: [6] Copying properties from node with ON CREATE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
       | +properties    | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | keyValue    |
       | ['name->A'] |
  Scenario: [7] Copying properties from literal map with ON CREATE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
       | +properties    | 2 |
   ✔  When executing control query:
   ?  Then the result should be (ignoring element order for lists):
       | keyValue                    |
       | ['name->bar', 'name2->baz'] |
      Step skipped: tests/tck/features/clauses/merge/Merge6.feature:165:5
Feature: Merge7 - Merge relationships - on match
  Scenario: [1] Using ON MATCH on created node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [2] Using ON MATCH on created relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +relationships | 1 |
  Scenario: [3] Using ON MATCH on a relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And the side effects should be:
       | +properties | 1 |
  Scenario: [4] Copying properties from node with ON MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +properties | 1 |
       | -properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | keyValue    |
       | ['name->A'] |
  Scenario: [5] Copying properties from literal map with ON MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +properties | 2 |
       | -properties | 1 |
   ✔  When executing control query:
   ?  Then the result should be (ignoring element order for lists):
       | keyValue                    |
       | ['name->baz', 'name2->baz'] |
      Step skipped: tests/tck/features/clauses/merge/Merge7.feature:141:5
Feature: Merge8 - Merge relationships - on match and on create
  Scenario: [1] Using ON CREATE and ON MATCH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 4        |
   ✔  And the side effects should be:
       | +relationships | 3 |
       | +properties    | 4 |
Feature: Merge9 - Merge clause interoperation with other clauses
  Scenario: [1] UNWIND with one MERGE
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 4        |
   ✔  And the side effects should be:
       | +nodes      | 4 |
       | +properties | 4 |
  Scenario: [2] UNWIND with multiple MERGE
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes         | 5 |
       | +relationships | 4 |
       | +labels        | 2 |
       | +properties    | 5 |
  Scenario: [3] Mixing MERGE with CREATE
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And the side effects should be:
       | +nodes         | 3 |
       | +relationships | 2 |
       | +labels        | 3 |
  Scenario: [4] MERGE after WITH with predicate and WITH with aggregation
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | prop |
       | 42   |
   ✔  And no side effects
Feature: Remove1 - Remove a Property
  Scenario: [1] Remove a single node property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | still_there |
       | false       |
   ✔  And the side effects should be:
       | -properties | 1 |
  Scenario: [2] Remove multiple node properties
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | props |
       | 1     |
   ✔  And the side effects should be:
       | -properties | 2 |
  Scenario: [3] Remove a single relationship property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | still_there |
       | false       |
   ✔  And the side effects should be:
       | -properties | 1 |
  Scenario: [4] Remove multiple relationship properties
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | props |
       | 1     |
   ✔  And the side effects should be:
       | -properties | 2 |
  Scenario: [5] Ignore null when removing property from a node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | null |
   ✔  And no side effects
  Scenario: [6] Ignore null when removing property from a relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n           |
       | ({num: 42}) |
   ✔  And no side effects
  Scenario: [7] Remove a missing node property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | totalNumberOfProps |
       | 0                  |
   ✔  And no side effects
Feature: Remove2 - Remove a Label
  Scenario: [1] Remove a single label from a node with a single label
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.num |
       | 42    |
   ✔  And the side effects should be:
       | -labels | 1 |
  Scenario: [2] Remove a single label from a node with two labels
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | labels(n) |
       | ['Bar']   |
   ✔  And the side effects should be:
       | -labels | 1 |
  Scenario: [3] Remove two labels from a node with three labels
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | labels(n) |
       | ['L2']    |
   ✔  And the side effects should be:
       | -labels | 2 |
  Scenario: [4] Remove a non-existent node label
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | labels(n) |
       | ['Foo']   |
   ✔  And no side effects
  Scenario: [5] Ignore null when removing a node label
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | null |
   ✔  And no side effects
Feature: Remove3 - Persistence of remove clause side effects
  Scenario: [1] Limiting to zero results after removing a property from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And the side effects should be:
       | -properties | 1 |
  Scenario: [2] Skipping all results after removing a property from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And the side effects should be:
       | -properties | 1 |
  Scenario: [3] Skipping and limiting to a few results after removing a property from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | -properties | 5 |
  Scenario: [4] Skipping zero results and limiting to all results after removing a property from nodes does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | -properties | 5 |
  Scenario: [5] Filtering after removing a property from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 2   |
       | 4   |
   ✔  And the side effects should be:
       | -properties | 5 |
  Scenario: [6] Aggregating in `RETURN` after removing a property from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | -properties | 5 |
  Scenario: [7] Aggregating in `WITH` after removing a property from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | -properties | 5 |
  Scenario: [8] Limiting to zero results after removing a label from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And the side effects should be:
       | -labels | 1 |
  Scenario: [9] Skipping all results after removing a label from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And the side effects should be:
       | -labels | 1 |
  Scenario: [10] Skipping and limiting to a few results after removing a label from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | -labels | 1 |
  Scenario: [11] Skipping zero result and limiting to all results after removing a label from nodes does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | -labels | 1 |
  Scenario: [12] Filtering after removing a label from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 2   |
       | 4   |
   ✔  And the side effects should be:
       | -labels | 1 |
  Scenario: [13] Aggregating in `RETURN` after removing a label from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | -labels | 1 |
  Scenario: [14] Aggregating in `WITH` after removing a label from nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | -labels | 1 |
  Scenario: [15] Limiting to zero results after removing a property from relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r |
   ✔  And the side effects should be:
       | -properties | 1 |
  Scenario: [16] Skipping all results after removing a property from relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r |
   ✔  And the side effects should be:
       | -properties | 1 |
  Scenario: [17] Skipping and limiting to a few results after removing a property from relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | -properties | 5 |
  Scenario: [18] Skipping zero result and limiting to all results after removing a property from relationships does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | -properties | 5 |
  Scenario: [19] Filtering after removing a property from relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 2   |
       | 4   |
   ✔  And the side effects should be:
       | -properties | 5 |
  Scenario: [20] Aggregating in `RETURN` after removing a property from relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | -properties | 5 |
  Scenario: [21] Aggregating in `WITH` after removing a property from relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | -properties | 5 |
Feature: Return1 - Return single variable (correct return of values according to their type)
  Scenario: [1] Returning a list property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                      |
       | ({numbers: [1, 2, 3]}) |
   ✔  And no side effects
  Scenario: [2] Fail when returning an undefined variable
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
Feature: Return2 - Return single expression (correctly projecting an expression)
  Scenario: [1] Arithmetic expressions should propagate null values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | null |
   ✔  And no side effects
  Scenario: [2] Returning a node property value
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.num |
       | 1     |
   ✔  And no side effects
  Scenario: [3] Missing node property should become null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.name |
       | null   |
   ✔  And no side effects
  Scenario: [4] Returning a relationship property value
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r.num |
       | 1     |
   ✔  And no side effects
  Scenario: [5] Missing relationship property should become null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r.name2 |
       | null    |
   ✔  And no side effects
  Scenario: [6] Adding a property and a literal in projection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | foo |
       | 2   |
   ✔  And no side effects
  Scenario: [7] Adding list properties in projection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | foo             |
       | [4, 5, 1, 2, 3] |
   ✔  And no side effects
  Scenario: [8] Returning label predicate expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | (n:Foo) |
       | true    |
       | false   |
   ✔  And no side effects
  Scenario: [9] Returning a projected map
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | {a: 1, b: 'foo'} |
       | {a: 1, b: 'foo'} |
   ✔  And no side effects
  Scenario: [10] Return count aggregation over an empty graph
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(a) > 0 |
       | false        |
   ✔  And no side effects
  Scenario: [11] RETURN does not lose precision on large integers
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p.id                |
       | 4611686018427387905 |
   ✔  And no side effects
  Scenario: [12] Projecting a list of nodes and relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r                  |
       | [(:A), [:T], (:B)] |
   ✔  And no side effects
  Scenario: [13] Projecting a map of nodes and relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m                                     |
       | {node1: (:A), rel: [:T], node2: (:B)} |
   ✔  And no side effects
  Scenario: [14] Do not fail when returning type of deleted relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | type(r) |
       | 'T'     |
   ✔  And the side effects should be:
       | -relationships | 1 |
  Scenario: [15] Fail when returning properties of deleted nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a EntityNotFound should be raised at runtime: DeletedEntityAccess
      Step skipped: tests/tck/features/clauses/return/Return2.feature:264:5
  Scenario: [16] Fail when returning labels of deleted nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a EntityNotFound should be raised at runtime: DeletedEntityAccess
      Step skipped: tests/tck/features/clauses/return/Return2.feature:278:5
  Scenario: [17] Fail when returning properties of deleted relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a EntityNotFound should be raised at runtime: DeletedEntityAccess
      Step skipped: tests/tck/features/clauses/return/Return2.feature:292:5
  Scenario: [18] Fail on projecting a non-existent function
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnknownFunction
Feature: Return3 - Return multiple expressions (if column order correct)
  Scenario: [1] Returning multiple expressions
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b    |
       | false | true |
   ✔  And no side effects
  Scenario: [2] Returning multiple node property values
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.name          | a.age | a.seasons             |
       | 'Philip J. Fry' | 2046  | [1, 2, 3, 4, 5, 6, 7] |
   ✔  And no side effects
  Scenario: [3] Projecting nodes and relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | foo  | bar  |
       | (:A) | [:T] |
   ✔  And no side effects
Feature: Return4 - Column renaming
  Scenario: [1] Honour the column name for RETURN items
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a         |
       | 'Someone' |
   ✔  And no side effects
  Scenario: [2] Support column renaming
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ColumnName   |
       | (:Singleton) |
   ✔  And no side effects
  Scenario: [3] Aliasing expressions
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a  | a.id |
       | 42 | 42   |
   ✔  And no side effects
  Scenario: [4] Keeping used expression 1
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | cOuNt( * ) |
       | 1          |
      Step failed:
      Defined: tests/tck/features/clauses/return/Return4.feature:93:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["count(*)"], values: {"count(*)": Integer(1)} }
  Scenario: [5] Keeping used expression 2
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | nOdEs( p ) |
   ✔  And no side effects
  Scenario: [6] Keeping used expression 3
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | coUnt( dIstInct p ) |
       | 0                   |
      Step failed:
      Defined: tests/tck/features/clauses/return/Return4.feature:125:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["coUnt(DISTINCT p)"], values: {"coUnt(DISTINCT p)": Integer(0)} }
  Scenario: [7] Keeping used expression 4
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | aVg(    n.aGe     ) |
       | null                |
      Step failed:
      Defined: tests/tck/features/clauses/return/Return4.feature:141:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["aVg(n.aGe)"], values: {"aVg(n.aGe)": Null} }
  Scenario: [8] Support column renaming for aggregations
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | columnName |
       | 11         |
   ✔  And no side effects
  Scenario: [9] Handle subexpression in aggregation also occurring as standalone expression with nested aggregation in a literal map
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | foo | bar | baz       |
       | 42  | 42  | {name: 1} |
   ✔  And no side effects
  Scenario: [10] Fail when returning multiple columns with same name
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: ColumnNameConflict
  Scenario: [11] Reusing variable names in RETURN
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | likeTime |
       | 20160614 |
   ✔  And no side effects
Feature: Return5 - Implicit grouping with distinct
  Scenario: [1] DISTINCT inside aggregation should work with lists in maps
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count |
       | 1     |
   ✔  And no side effects
  Scenario: [2] DISTINCT on nullable values
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.name     |
       | 'Florescu' |
       | null       |
   ✔  And no side effects
  Scenario: [3] DISTINCT inside aggregation should work with nested lists in maps
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count |
       | 1     |
   ✔  And no side effects
  Scenario: [4] DISTINCT inside aggregation should work with nested lists of maps in maps
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count |
       | 1     |
   ✔  And no side effects
  Scenario: [5] Aggregate on list values
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.color  | count(*) |
       | ['red']  | 2        |
       | ['blue'] | 1        |
   ✔  And no side effects
Feature: Return6 - Implicit grouping with aggregates
  Scenario: [1] Return count aggregation over nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n  | count |
       | 42 | 1     |
   ✔  And no side effects
  Scenario: [2] Projecting an arithmetic expression with aggregation
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a          | count(a) + 3 |
       | ({id: 42}) | 4            |
   ✔  And no side effects
  Scenario: [3] Aggregating by a list property has a correct definition of equality
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count |
       | 2     |
   ✔  And no side effects
  Scenario: [4] Support multiple divisions in aggregate function
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count |
       | 2     |
   ✔  And no side effects
  Scenario: [5] Aggregates inside normal functions
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | size(collect(a)) |
       | 11               |
   ✔  And no side effects
  Scenario: [6] Handle aggregates inside non-aggregate expressions
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.name | {foo: a.name='Andres', kids: collect(child.name)} |
   ✔  And no side effects
  Scenario: [7] Aggregate on property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.num | count(*) |
       | 42    | 1        |
       | 33    | 2        |
   ✔  And no side effects
  Scenario: [8] Handle aggregation on functions
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b  | avg(length(p)) |
       | () | 1.0            |
       | () | 1.0            |
   ✔  And no side effects
  Scenario: [9] Aggregates with arithmetics
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c  |
       | 10 |
   ✔  And no side effects
  Scenario: [10] Multiple aggregates on same variable
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(n) | collect(n) |
       | 1        | [()]       |
   ✔  And no side effects
  Scenario: [11] Counting matches
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 100      |
   ✔  And no side effects
  Scenario: [12] Counting matches per group
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | count(*) |
       | (:L) | 2        |
   ✔  And no side effects
  Scenario: [13] Returning the minimum length of paths
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | name | others     | len |
       | 'a'  | ['c', 'b'] | 1   |
      Step skipped: tests/tck/features/clauses/return/Return6.feature:246:5
  Scenario: [14] Aggregates in aggregates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NestedAggregation
  Scenario: [15] Using `rand()` in aggregations
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NonConstantExpression
  Scenario: [16] Aggregation on complex expressions
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | me                  | you                | sum |
       | ({name: 'Michael'}) | ({name: 'Andres'}) | -7  |
       | ({name: 'Michael'}) | ({name: 'Peter'})  | 0   |
   ✔  And no side effects
  Scenario: [17] Handle constants and parameters inside an expression which contains an aggregation expression
   ✔  Given an empty graph
   ✔  And parameters are:
       | age | 38 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | $age + avg(person.age) - 1000 |
       | null                          |
   ✔  And no side effects
  Scenario: [18] Handle returned variables inside an expression which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | age | age + count(you.age) |
   ✔  And no side effects
  Scenario: [19] Handle returned property accesses inside an expression which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | me.age | me.age + count(you.age) |
   ✔  And no side effects
  Scenario: [20] Fail if not returned variables are used inside an expression which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: AmbiguousAggregationExpression
  Scenario: [21] Fail if more complex expressions, even if returned, are used inside expression which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: AmbiguousAggregationExpression
Feature: Return7 - Return all variables
  Scenario: [1] Return all variables
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a        | b  | p                   |
       | (:Start) | () | <(:Start)-[:T]->()> |
   ✔  And no side effects
  Scenario: [2] Fail when using RETURN * without variables in scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NoVariablesInScope
Feature: Return8 - Return clause interoperation with other clauses
  Scenario: [1] Return aggregation after With filtering
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And no side effects
Feature: ReturnOrderBy1 - Order by a single variable (correct order of values according to their type)
  Scenario: [1] ORDER BY should order booleans in the expected order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | bools |
       | false |
       | true  |
   ✔  And no side effects
  Scenario: [2] ORDER BY DESC should order booleans in the expected order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | bools |
       | true  |
       | false |
   ✔  And no side effects
  Scenario: [3] ORDER BY should order strings in the expected order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | strings |
       | ''      |
       | ' '     |
       | '.*'    |
       | 'one'   |
   ✔  And no side effects
  Scenario: [4] ORDER BY DESC should order strings in the expected order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | strings |
       | 'one'   |
       | '.*'    |
       | ' '     |
       | ''      |
   ✔  And no side effects
  Scenario: [5] ORDER BY should order ints in the expected order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | ints |
       | 1    |
       | 2    |
       | 3    |
   ✔  And no side effects
  Scenario: [6] ORDER BY DESC should order ints in the expected order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | ints |
       | 3    |
       | 2    |
       | 1    |
   ✔  And no side effects
  Scenario: [7] ORDER BY should order floats in the expected order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | floats |
       | 1.3    |
       | 1.5    |
       | 999.99 |
   ✔  And no side effects
  Scenario: [8] ORDER BY DESC should order floats in the expected order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | floats |
       | 999.99 |
       | 1.5    |
       | 1.3    |
   ✔  And no side effects
  Scenario: [9] ORDER BY should order lists in the expected order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | lists     |
       | []        |
       | ['a']     |
       | ['a', 1]  |
       | [1]       |
       | [1, 'a']  |
       | [1, null] |
       | [null, 1] |
       | [null, 2] |
   ✔  And no side effects
  Scenario: [10] ORDER BY DESC should order lists in the expected order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | lists     |
       | [null, 2] |
       | [null, 1] |
       | [1, null] |
       | [1, 'a']  |
       | [1]       |
       | ['a', 1]  |
       | ['a']     |
       | []        |
   ✔  And no side effects
  Scenario: [11] ORDER BY should order distinct types in the expected order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | types             |
       | {a: 'map'}        |
       | (:N)              |
       | [:REL]            |
       | ['list']          |
       | <(:N)-[:REL]->()> |
       | 'text'            |
       | false             |
       | 1.5               |
       | NaN               |
       | null              |
   ✔  And no side effects
  Scenario: [12] ORDER BY DESC should order distinct types in the expected order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | types             |
       | null              |
       | NaN               |
       | 1.5               |
       | false             |
       | 'text'            |
       | <(:N)-[:REL]->()> |
       | ['list']          |
       | [:REL]            |
       | (:N)              |
       | {a: 'map'}        |
   ✔  And no side effects
Feature: ReturnOrderBy2 - Order by a single expression (order of projection)
  Scenario: [1] ORDER BY should return results in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | prop |
       | -5   |
       | 1    |
       | 3    |
   ✔  And no side effects
  Scenario: [2] ORDER BY DESC should return results in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | prop |
       | 3    |
       | 1    |
       | -5   |
   ✔  And no side effects
  Scenario: [3] Sort on aggregated function
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n.division | max(n.age) |
       | 'A'        | 22         |
       | 'B'        | 44         |
       | 'C'        | 55         |
   ✔  And no side effects
  Scenario: [4] Support sort and distinct
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | a             |
       | ({name: 'A'}) |
       | ({name: 'B'}) |
       | ({name: 'C'}) |
   ✔  And no side effects
  Scenario: [5] Support ordering by a property after being distinct-ified
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | b    |
       | (:B) |
   ✔  And no side effects
  Scenario: [6] Count star should count everything in scope
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | count(*) |
       | (:L1) | 1        |
       | (:L2) | 1        |
       | (:L3) | 1        |
   ✔  And no side effects
  Scenario: [7] Ordering with aggregation
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n.name  | foo |
       | 'nisse' | 1   |
   ✔  And no side effects
  Scenario: [8] Returning all variables with ordering
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n          |
       | ({id: 1})  |
       | ({id: 10}) |
   ✔  And no side effects
  Scenario: [9] Using aliased DISTINCT expression in ORDER BY
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | id |
       | 10 |
       | 1  |
   ✔  And no side effects
  Scenario: [10] Returned columns do not change from using ORDER BY
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n          |
       | ({id: 1})  |
       | ({id: 10}) |
   ✔  And no side effects
  Scenario: [11] Aggregates ordered by arithmetics
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | x  |
       | 30 |
   ✔  And no side effects
  Scenario: [12] Aggregation of named paths
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then the result should be, in order (ignoring element order for lists):
       | paths                                                    | l |
       | [[(:A), (:B)], [(:C), (:D)], [(:D), (:E)], [(:E), (:F)]] | 1 |
       | [[(:C), (:D), (:E)], [(:D), (:E), (:F)]]                 | 2 |
       | [[(:C), (:D), (:E), (:F)]]                               | 3 |
      Step skipped: tests/tck/features/clauses/return-orderby/ReturnOrderBy2.feature:259:5
  Scenario: [13] Fail when sorting on variable removed by DISTINCT
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario: [14] Fail on aggregation in ORDER BY after RETURN
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
Feature: ReturnOrderBy3 - Order by multiple expressions (order obey priority of expressions)
  Scenario: [1] Sort on aggregate function and normal property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n.division | count(*) |
       | 'Sweden'   | 2        |
       | 'England'  | 1        |
       | 'Germany'  | 1        |
   ✔  And no side effects
Feature: ReturnOrderBy4 - Order by in combination with projection
  Scenario: [1] ORDER BY of a column introduced in RETURN should return salient results in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | p |
       | 0 |
       | 1 |
   ✔  And no side effects
  Scenario: [2] Handle projections with ORDER BY
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | rank |
       | 1    |
       | 2    |
       | 3    |
       | 4    |
       | 5    |
   ✔  And no side effects
Feature: ReturnOrderBy5 - Order by in combination with column renaming
  Scenario: [1] Renaming columns before ORDER BY should return results in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n  |
       | -5 |
       | 1  |
       | 3  |
   ✔  And no side effects
Feature: ReturnOrderBy6 - Aggregation expressions in order by
  Scenario: [1] Handle constants and parameters inside an order by item which contains an aggregation expression
   ✔  Given an empty graph
   ✔  And parameters are:
       | age | 38 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | avgAge |
       | null   |
   ✔  And no side effects
  Scenario: [2] Handle returned aliases inside an order by item which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | age | cnt |
   ✔  And no side effects
  Scenario: [3] Handle returned property accesses inside an order by item which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | age | cnt |
   ✔  And no side effects
  Scenario: [4] Fail if not returned variables are used inside an order by item which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario: [5] Fail if more complex expressions, even if returned, are used inside an order by item which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: AmbiguousAggregationExpression
Feature: ReturnSkipLimit1 - Skip
  Scenario: [1] Start the result from the second row
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n             |
       | ({name: 'C'}) |
       | ({name: 'D'}) |
       | ({name: 'E'}) |
   ✔  And no side effects
  Scenario: [2] Start the result from the second row by param
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | skipAmount | 2 |
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n             |
       | ({name: 'C'}) |
       | ({name: 'D'}) |
       | ({name: 'E'}) |
   ✔  And no side effects
  Scenario: [3] SKIP with an expression that does not depend on variables
   ✔  Given any graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | nonEmpty |
       | true     |
   ✔  And no side effects
  Scenario: [4] Accept skip zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And no side effects
  Scenario: [5] SKIP with an expression that depends on variables should fail
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NonConstantExpression
  Scenario: [6] Negative parameter for SKIP should fail
   ✔  Given any graph
   ✔  And having executed:
   ✔  And parameters are:
       | _skip | -1 |
   ✔  When executing query:
   ?  Then a SyntaxError should be raised at runtime: NegativeIntegerArgument
      Step skipped: tests/tck/features/clauses/return-skip-limit/ReturnSkipLimit1.feature:137:5
  Scenario: [7] Negative SKIP should fail
   ✔  Given any graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NegativeIntegerArgument
  Scenario: [8] Floating point parameter for SKIP should fail
   ✔  Given any graph
   ✔  And having executed:
   ✔  And parameters are:
       | _limit | 1.5 |
   ✔  When executing query:
   ?  Then a SyntaxError should be raised at runtime: InvalidArgumentType
      Step skipped: tests/tck/features/clauses/return-skip-limit/ReturnSkipLimit1.feature:169:5
  Scenario: [9] Floating point SKIP should fail
   ✔  Given any graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario: [10] Fail when using non-constants in SKIP
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NonConstantExpression
  Scenario: [11] Fail when using negative value in SKIP
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NegativeIntegerArgument
Feature: ReturnSkipLimit2 - Limit
  Scenario: [1] Limit to two hits
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i |
       | 1 |
       | 1 |
   ✔  And no side effects
  Scenario: [2] Limit to two hits with explicit order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n             |
       | ({name: 'A'}) |
       | ({name: 'B'}) |
   ✔  And no side effects
  Scenario: [3] LIMIT 0 should return an empty result
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And no side effects
  Scenario: [4] Handle ORDER BY with LIMIT 1
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | name    |
       | 'Craig' |
   ✔  And no side effects
  Scenario: [5] ORDER BY with LIMIT 0 should not generate errors
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | name |
   ✔  And no side effects
  Scenario: [6] LIMIT with an expression that does not depend on variables
   ✔  Given any graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count |
       | 2     |
   ✔  And no side effects
  Scenario: [7] Limit to more rows than actual results 1
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | x |
       | 3 |
       | 2 |
       | 1 |
   ✔  And no side effects
  Scenario: [8] Limit to more rows than actual results 2
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n.num | count(*) |
       | 1     | 1        |
       | 2     | 1        |
   ✔  And no side effects
  Scenario: [9] Fail when using non-constants in LIMIT
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NonConstantExpression
  Scenario: [10] Negative parameter for LIMIT should fail
   ✔  Given any graph
   ✔  And having executed:
   ✔  And parameters are:
       | _limit | -1 |
   ✔  When executing query:
   ?  Then a SyntaxError should be raised at runtime: NegativeIntegerArgument
      Step skipped: tests/tck/features/clauses/return-skip-limit/ReturnSkipLimit2.feature:203:5
  Scenario: [11] Negative parameter for LIMIT with ORDER BY should fail
   ✔  Given any graph
   ✔  And having executed:
   ✔  And parameters are:
       | _limit | -1 |
   ✔  When executing query:
   ?  Then a SyntaxError should be raised at runtime: NegativeIntegerArgument
      Step skipped: tests/tck/features/clauses/return-skip-limit/ReturnSkipLimit2.feature:220:5
  Scenario: [12] Fail when using negative value in LIMIT 1
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NegativeIntegerArgument
  Scenario: [13] Fail when using negative value in LIMIT 2
   ✔  Given any graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NegativeIntegerArgument
  Scenario: [14] Floating point parameter for LIMIT should fail
   ✔  Given any graph
   ✔  And having executed:
   ✔  And parameters are:
       | _limit | 1.5 |
   ✔  When executing query:
   ?  Then a SyntaxError should be raised at runtime: InvalidArgumentType
      Step skipped: tests/tck/features/clauses/return-skip-limit/ReturnSkipLimit2.feature:262:5
  Scenario: [15] Floating point parameter for LIMIT with ORDER BY should fail
   ✔  Given any graph
   ✔  And having executed:
   ✔  And parameters are:
       | _limit | 1.5 |
   ✔  When executing query:
   ?  Then a SyntaxError should be raised at runtime: InvalidArgumentType
      Step skipped: tests/tck/features/clauses/return-skip-limit/ReturnSkipLimit2.feature:279:5
  Scenario: [16] Fail when using floating point in LIMIT 1
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario: [17] Fail when using floating point in LIMIT 2
   ✔  Given any graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: ReturnSkipLimit3 - Skip and limit
  Scenario: [1] Get rows in the middle
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n             |
       | ({name: 'C'}) |
       | ({name: 'D'}) |
   ✔  And no side effects
  Scenario: [2] Get rows in the middle by param
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | s | 2 |
       | l | 2 |
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n             |
       | ({name: 'C'}) |
       | ({name: 'D'}) |
   ✔  And no side effects
  Scenario: [3] Limiting amount of rows when there are fewer left than the LIMIT argument
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | a.count |
       | 10      |
       | 11      |
       | 12      |
       | 13      |
       | 14      |
       | 15      |
   ✔  And no side effects
Feature: Set1 - Set a Property
  Scenario: [1] Set a property
   ✔  Given any graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                      |
       | (:A {name: 'Michael'}) |
   ✔  And the side effects should be:
       | +properties | 1 |
       | -properties | 1 |
  Scenario: [2] Set a property to an expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                              |
       | (:A {name: 'Andres was here'}) |
   ✔  And the side effects should be:
       | +properties | 1 |
       | -properties | 1 |
  Scenario: [3] Set a property by selecting the node using a simple expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                    |
       | (:A {name: 'neo4j'}) |
   ✔  And the side effects should be:
       | +properties | 1 |
  Scenario: [4] Set a property by selecting the relationship using a simple expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r                      |
       | [:REL {name: 'neo4j'}] |
   ✔  And the side effects should be:
       | +properties | 1 |
  Scenario: [5] Adding a list property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x               |
       | [0.5, 1.0, 1.5] |
   ✔  And the side effects should be:
       | +properties | 1 |
  Scenario: [6] Concatenate elements onto a list property
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.numbers       |
       | [1, 2, 3, 4, 5] |
   ✘  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
      Step failed:
      Defined: tests/tck/features/clauses/set/Set1.feature:138:5
      Matched: tests/tck/main.rs:444:1
      Step panicked. Captured output: assertion `left == right` failed: properties_set mismatch
        left: 2
       right: 1
  Scenario: [7] Concatenate elements in reverse onto a list property
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.numbers       |
       | [1, 2, 3, 4, 5] |
   ✘  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
      Step failed:
      Defined: tests/tck/features/clauses/set/Set1.feature:153:5
      Matched: tests/tck/main.rs:444:1
      Step panicked. Captured output: assertion `left == right` failed: properties_set mismatch
        left: 2
       right: 1
  Scenario: [8] Ignore null when setting property
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | null |
   ✔  And no side effects
  Scenario: [9] Failing when using undefined variable in SET
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario: [10] Failing when setting a list of maps as a property
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidPropertyType
      Step skipped: tests/tck/features/clauses/set/Set1.feature:187:5
  Scenario: [11] Set multiple node properties
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                                    |
       | (:X {name: 'A', name2: 'B', num: 5}) |
   ✔  And the side effects should be:
       | +properties | 3 |
Feature: Set2 - Set a Property to Null
  Scenario: [1] Setting a node property to null removes the existing property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                    |
       | (:A {property2: 46}) |
   ✔  And the side effects should be:
       | -properties | 1 |
  Scenario: [2] Setting a node property to null removes the existing property, but not before SET
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n              |
       | (:A {age: 35}) |
   ✔  And the side effects should be:
       | -properties | 1 |
  Scenario: [3] Setting a relationship property to null removes the existing property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r                      |
       | [:REL {property2: 24}] |
   ✔  And the side effects should be:
       | -properties | 1 |
Feature: Set3 - Set a Label
  Scenario: [1] Add a single label to a node with no label
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n      |
       | (:Foo) |
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [2] Adding multiple labels to a node with no label
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n          |
       | (:Foo:Bar) |
   ✔  And the side effects should be:
       | +labels | 2 |
  Scenario: [3] Add a single label to a node with an existing label
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n        |
       | (:A:Foo) |
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [4] Adding multiple labels to a node with an existing label
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n            |
       | (:A:Foo:Bar) |
   ✔  And the side effects should be:
       | +labels | 2 |
  Scenario: [5] Ignore whitespace before colon 1
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | labels(n) |
       | ['Foo']   |
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [6] Ignore whitespace before colon 2
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | labels(n)      |
       | ['Foo', 'Bar'] |
      Step skipped: tests/tck/features/clauses/set/Set3.feature:135:5
  Scenario: [7] Ignore whitespace before colon 3
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | labels(n)      |
       | ['Foo', 'Bar'] |
      Step skipped: tests/tck/features/clauses/set/Set3.feature:153:5
  Scenario: [8] Ignore null when setting label
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | null |
   ✔  And no side effects
Feature: Set4 - Set all properties with a map
  Scenario: [1] Set multiple properties with a property map
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                                    |
       | (:X {name: 'A', name2: 'B', num: 5}) |
   ✔  And the side effects should be:
       | +properties | 3 |
  Scenario: [2] Non-existent values in a property map are removed with SET
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                          |
       | (:X {name: 'B', baz: 'C'}) |
   ✔  And the side effects should be:
       | +properties | 2 |
       | -properties | 2 |
  Scenario: [3] Null values in a property map are removed with SET
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                          |
       | (:X {name: 'B', baz: 'C'}) |
   ✔  And the side effects should be:
       | +properties | 2 |
       | -properties | 2 |
  Scenario: [4] All properties are removed if node is set to empty property map
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:X) |
   ✔  And the side effects should be:
       | -properties | 2 |
  Scenario: [5] Ignore null when setting properties using an overriding map
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | null |
   ✔  And no side effects
Feature: Set5 - Set multiple properties with a map
  Scenario: [1] Ignore null when setting properties using an appending map
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | null |
   ✔  And no side effects
  Scenario: [2] Overwrite values when using +=
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                            |
       | (:X {name: 'A', name2: 'C'}) |
   ✔  And the side effects should be:
       | +properties | 1 |
       | -properties | 1 |
  Scenario: [3] Retain old values when using +=
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                            |
       | (:X {name: 'A', name2: 'B'}) |
   ✔  And the side effects should be:
       | +properties | 1 |
  Scenario: [4] Explicit null values in a map remove old values
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                 |
       | (:X {name2: 'B'}) |
   ✔  And the side effects should be:
       | -properties | 1 |
  Scenario: [5] Set an empty map when using += has no effect
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                            |
       | (:X {name: 'A', name2: 'B'}) |
   ✔  And no side effects
Feature: Set6 - Persistence of set clause side effects
  Scenario: [1] Limiting to zero results after setting a property on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And the side effects should be:
       | +properties | 1 |
       | -properties | 1 |
  Scenario: [2] Skipping all results after setting a property on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And the side effects should be:
       | +properties | 1 |
       | -properties | 1 |
  Scenario: [3] Skipping and limiting to a few results after setting a property on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | +properties | 5 |
       | -properties | 5 |
  Scenario: [4] Skipping zero results and limiting to all results after setting a property on nodes does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | +properties | 5 |
       | -properties | 5 |
  Scenario: [5] Filtering after setting a property on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 2   |
       | 4   |
       | 6   |
   ✔  And the side effects should be:
       | +properties | 5 |
       | -properties | 5 |
  Scenario: [6] Aggregating in `RETURN` after setting a property on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 20  |
   ✔  And the side effects should be:
       | +properties | 5 |
       | -properties | 5 |
  Scenario: [7] Aggregating in `WITH` after setting a property on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 20  |
   ✔  And the side effects should be:
       | +properties | 5 |
       | -properties | 5 |
  Scenario: [8] Limiting to zero results after adding a label on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [9] Skipping all results after adding a label on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [10] Skipping and limiting to a few results after adding a label on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [11] Skipping zero result and limiting to all results after adding a label on nodes does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [12] Filtering after adding a label on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 2   |
       | 4   |
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [13] Aggregating in `RETURN` after adding a label on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [14] Aggregating in `WITH` after adding a label on nodes affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 15  |
   ✔  And the side effects should be:
       | +labels | 1 |
  Scenario: [15] Limiting to zero results after setting a property on relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r |
   ✔  And the side effects should be:
       | +properties | 1 |
       | -properties | 1 |
  Scenario: [16] Skipping all results after setting a property on relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r |
   ✔  And the side effects should be:
       | +properties | 1 |
       | -properties | 1 |
  Scenario: [17] Skipping and limiting to a few results after setting a property on relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | +properties | 5 |
       | -properties | 5 |
  Scenario: [18] Skipping zero result and limiting to all results after setting a property on relationships does not affect the result set nor the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
       | 42  |
   ✔  And the side effects should be:
       | +properties | 5 |
       | -properties | 5 |
  Scenario: [19] Filtering after setting a property on relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | num |
       | 2   |
       | 4   |
       | 6   |
   ✔  And the side effects should be:
       | +properties | 5 |
       | -properties | 5 |
  Scenario: [20] Aggregating in `RETURN` after setting a property on relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 20  |
   ✔  And the side effects should be:
       | +properties | 5 |
       | -properties | 5 |
  Scenario: [21] Aggregating in `WITH` after setting a property on relationships affects the result set but not the side effects
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum |
       | 20  |
   ✔  And the side effects should be:
       | +properties | 5 |
       | -properties | 5 |
Feature: Union1 - Union
  Scenario: [1] Two elements, both unique, distinct
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 1 |
       | 2 |
   ✔  And no side effects
  Scenario: [2] Three elements, two unique, distinct
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 2 |
       | 1 |
   ✔  And no side effects
  Scenario: [3] Two single-column inputs, one with duplicates, distinct
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 2 |
       | 1 |
       | 3 |
       | 4 |
   ✔  And no side effects
  Scenario: [4] Should be able to create text output from union queries
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | (:A) |
       | (:B) |
   ✔  And no side effects
  Scenario: [5] Failing when UNION has different columns
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: DifferentColumnsInUnion
Feature: Union2 - Union All
  Scenario: [1] Two elements, both unique, not distinct
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 1 |
       | 2 |
   ✔  And no side effects
  Scenario: [2] Three elements, two unique, not distinct
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 2 |
       | 1 |
       | 2 |
   ✔  And no side effects
  Scenario: [3] Two single-column inputs, one with duplicates, not distinct
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 2 |
       | 1 |
       | 2 |
       | 3 |
       | 3 |
       | 4 |
   ✔  And no side effects
  Scenario: [4] Should be able to create text output from union all queries
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | (:A) |
       | (:B) |
   ✔  And no side effects
  Scenario: [5] Failing when UNION ALL has different columns
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: DifferentColumnsInUnion
Feature: Union3 - Union in combination with Union All
  Scenario: [1] Failing when mixing UNION and UNION ALL
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidClauseComposition
  Scenario: [2] Failing when mixing UNION ALL and UNION
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidClauseComposition
Feature: Unwind1
  Scenario: [1] Unwinding a list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 1 |
       | 2 |
       | 3 |
   ✔  And no side effects
  Scenario: [2] Unwinding a range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 1 |
       | 2 |
       | 3 |
   ✔  And no side effects
  Scenario: [3] Unwinding a concatenation of lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 1 |
       | 2 |
       | 3 |
       | 4 |
       | 5 |
       | 6 |
   ✔  And no side effects
  Scenario: [4] Unwinding a collected unwound expression
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 1 |
       | 2 |
   ✔  And no side effects
  Scenario: [5] Unwinding a collected expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | node.id |
       | 1       |
       | 2       |
   ✔  And no side effects
  Scenario: [6] Creating nodes from an unwound parameter list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | events | [{year: 2016, id: 1}, {year: 2016, id: 2}] |
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | x |
       | 1 |
       | 2 |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 2 |
       | +labels        | 1 |
       | +properties    | 2 |
  Scenario: [7] Double unwinding a list of lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | y |
       | 1 |
       | 2 |
       | 3 |
       | 4 |
       | 5 |
       | 6 |
   ✔  And no side effects
  Scenario: [8] Unwinding the empty list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | empty |
   ✔  And no side effects
  Scenario: [9] Unwinding null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | nil |
   ✔  And no side effects
  Scenario: [10] Unwinding list with duplicates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duplicate |
       | 1         |
       | 1         |
       | 2         |
       | 2         |
       | 3         |
       | 3         |
       | 4         |
       | 4         |
       | 5         |
       | 5         |
   ✔  And no side effects
  Scenario: [11] Unwind does not prune context
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list      | x |
       | [1, 2, 3] | 1 |
       | [1, 2, 3] | 2 |
       | [1, 2, 3] | 3 |
   ✔  And no side effects
  Scenario: [12] Unwind does not remove variables from scope
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b2   |
       | (:S) | (:E) |
   ✔  And no side effects
  Scenario: [13] Multiple unwinds after each other
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x | xs     | y | ys     | z | zs     |
       | 1 | [1, 2] | 3 | [3, 4] | 5 | [5, 6] |
       | 1 | [1, 2] | 3 | [3, 4] | 6 | [5, 6] |
       | 1 | [1, 2] | 4 | [3, 4] | 5 | [5, 6] |
       | 1 | [1, 2] | 4 | [3, 4] | 6 | [5, 6] |
       | 2 | [1, 2] | 3 | [3, 4] | 5 | [5, 6] |
       | 2 | [1, 2] | 3 | [3, 4] | 6 | [5, 6] |
       | 2 | [1, 2] | 4 | [3, 4] | 5 | [5, 6] |
       | 2 | [1, 2] | 4 | [3, 4] | 6 | [5, 6] |
   ✔  And no side effects
  Scenario: [14] Unwind with merge
   ✔  Given an empty graph
   ✔  And parameters are:
       | props | [{login: 'login1', name: 'name1'}, {login: 'login2', name: 'name2'}] |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p.name  | p.login  |
       | 'name1' | 'login1' |
       | 'name2' | 'login2' |
   ✔  And the side effects should be:
       | +nodes      | 2 |
       | +labels     | 1 |
       | +properties | 4 |
Feature: With1 - Forward single variable
  Scenario: [1] Forwarind a node variable 1
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    |
       | (:A) | (:B) |
   ✔  And no side effects
  Scenario: [2] Forwarind a node variable 2
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | x    |
       | (:A) | (:B) | (:X) |
   ✔  And no side effects
  Scenario: [3] Forwarding a relationship variable
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | rel   |
       | [:T1] |
       | [:T2] |
   ✔  And no side effects
  Scenario: [4] Forwarding a path variable
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | <()> |
   ✔  And no side effects
  Scenario: [5] Forwarding null
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b |
   ✔  And no side effects
  Scenario: [6] Forwarding a node variable possibly null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a              | b              |
       | (:A {num: 42}) | (:B {num: 46}) |
   ✔  And no side effects
Feature: With2 - Forward single expression
  Scenario: [1] Forwarding a property to express a join
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b                       |
       | (:End {num: 42, id: 0}) |
   ✔  And no side effects
  Scenario: [2] Forwarding a nested map literal
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | nestedMap.name.name2 |
       | 'baz'                |
   ✔  And no side effects
Feature: With3 - Forward multiple expressions
  Scenario: [1] Forwarding multiple node and relationship variables
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | rel           |
       | [:T1 {id: 0}] |
       | [:T2 {id: 1}] |
   ✔  And no side effects
Feature: With4 - Variable aliasing
  Scenario: [1] Aliasing relationship variable
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | rel   |
       | [:T1] |
       | [:T2] |
   ✔  And no side effects
  Scenario: [2] Aliasing expression to new variable name
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b                |
       | (:End {num: 42}) |
   ✔  And no side effects
  Scenario: [3] Aliasing expression to existing variable name
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n            |
       | 'Ann Darrow' |
       | 'King Kong'  |
   ✔  And no side effects
  Scenario: [4] Fail when forwarding multiple aliases with the same name
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: ColumnNameConflict
  Scenario: [5] Fail when not aliasing expressions in WITH
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: NoExpressionAlias
  Scenario: [6] Reusing variable names in WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | likeTime |
       | 20160614 |
   ✔  And no side effects
  Scenario: [7] Multiple aliasing and backreferencing
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m.second |
       | 0        |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
Feature: With5 - Implicit grouping with DISTINCT
  Scenario: [1] DISTINCT on an expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name |
       | 'A'  |
       | 'B'  |
   ✔  And no side effects
  Scenario: [2] Handling DISTINCT with lists in maps
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And no side effects
Feature: With6 - Implicit grouping with aggregates
  Scenario: [1] Implicit grouping with single expression as grouping key and single aggregation
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name | relCount |
       | 'A'  | 2        |
       | 'B'  | 1        |
   ✔  And no side effects
  Scenario: [2] Implicit grouping with single relationship variable as grouping key and single aggregation
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | rel   |
       | [:T1] |
       | [:T2] |
   ✔  And no side effects
  Scenario: [3] Implicit grouping with multiple node and relationship variables as grouping key and single aggregation
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | rel   |
       | [:T1] |
       | [:T2] |
   ✔  And no side effects
  Scenario: [4] Implicit grouping with single path variable as grouping key and single aggregation
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | nodes                    |
       | [({num: 1}), ({num: 2})] |
       | [({num: 3}), ({num: 4})] |
   ✔  And no side effects
  Scenario: [5] Handle constants and parameters inside an expression which contains an aggregation expression
   ✔  Given an empty graph
   ✔  And parameters are:
       | age | 38 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | agg  |
       | null |
   ✔  And no side effects
  Scenario: [6] Handle projected variables inside an expression which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | age | agg |
   ✔  And no side effects
  Scenario: [7] Handle projected property accesses inside an expression which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | age | agg |
   ✔  And no side effects
  Scenario: [8] Fail if not projected variables are used inside an expression which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: AmbiguousAggregationExpression
  Scenario: [9] Fail if more complex expression, even if projected, are used inside expression which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: AmbiguousAggregationExpression
Feature: With7 - WITH on WITH
  Scenario: [1] A simple pattern with one bound endpoint
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | r      | b    |
       | (:A) | [:REL] | (:B) |
   ✔  And no side effects
  Scenario: [2] Multiple WITHs using a predicate and aggregation
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And no side effects
Feature: WithOrderBy1 - Order by a single variable
  Scenario: [1] Sort booleans in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | bools |
       | false |
   ✔  And no side effects
  Scenario: [2] Sort booleans in descending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | bools |
       | true  |
   ✔  And no side effects
  Scenario: [3] Sort integers in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | ints |
       | 1    |
       | 2    |
   ✔  And no side effects
  Scenario: [4] Sort integers in descending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | ints |
       | 3    |
       | 2    |
   ✔  And no side effects
  Scenario: [5] Sort floats in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | floats |
       | 1.3    |
       | 1.5    |
   ✔  And no side effects
  Scenario: [6] Sort floats in descending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | floats |
       | 999.99 |
       | 1.5    |
   ✔  And no side effects
  Scenario: [7] Sort strings in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | strings |
       | ''      |
       | ' '     |
   ✔  And no side effects
  Scenario: [8] Sort strings in descending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | strings |
       | 'one'   |
       | '.*'    |
   ✔  And no side effects
  Scenario: [9] Sort lists in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | lists    |
       | []       |
       | ['a']    |
       | ['a', 1] |
       | [1]      |
   ✔  And no side effects
  Scenario: [10] Sort lists in descending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | lists     |
       | [null, 2] |
       | [null, 1] |
       | [1, null] |
       | [1, 'a']  |
   ✔  And no side effects
  Scenario: [11] Sort dates in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | dates        |
       | '1910-05-06' |
       | '1980-10-24' |
   ✔  And no side effects
  Scenario: [12] Sort dates in descending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | dates        |
       | '1985-05-06' |
       | '1984-10-12' |
   ✔  And no side effects
  Scenario: [13] Sort local times in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | localtimes           |
       | '10:35'              |
       | '12:30:14.645876123' |
       | '12:31:14.645876123' |
   ✔  And no side effects
  Scenario: [14] Sort local times in descending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | localtimes           |
       | '12:35:13'           |
       | '12:31:14.645876124' |
       | '12:31:14.645876123' |
   ✔  And no side effects
  Scenario: [15] Sort times in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | times                      |
       | '12:35:15+05:00'           |
       | '12:30:14.645876123+01:01' |
       | '12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario: [16] Sort times in descending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | times                      |
       | '10:35-08:00'              |
       | '12:31:14.645876124+01:00' |
       | '12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario: [17] Sort local date times in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | localdatetimes                  |
       | '0001-01-01T01:01:01.000000001' |
       | '1980-12-11T12:31:14'           |
       | '1984-10-11T12:30:14.000000012' |
   ✔  And no side effects
  Scenario: [18] Sort local date times in descending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | localdatetimes                  |
       | '9999-09-09T09:59:59.999999999' |
       | '1984-10-11T12:31:14.645876123' |
       | '1984-10-11T12:30:14.000000012' |
   ✔  And no side effects
  Scenario: [19] Sort date times in ascending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | datetimes                             |
       | '0001-01-01T01:01:01.000000001-11:59' |
       | '1980-12-11T12:31:14-11:59'           |
       | '1984-10-11T12:31:14.645876123+00:17' |
   ✔  And no side effects
  Scenario: [20] Sort date times in descending order
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | datetimes                             |
       | '9999-09-09T09:59:59.999999999+11:59' |
       | '1984-10-11T12:30:14.000000012+00:15' |
       | '1984-10-11T12:31:14.645876123+00:17' |
   ✔  And no side effects
  Scenario: [21] Sort distinct types in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | types             |
       | {a: 'map'}        |
       | (:N)              |
       | [:REL]            |
       | ['list']          |
       | <(:N)-[:REL]->()> |
   ✔  And no side effects
  Scenario: [22] Sort distinct types in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | types  |
       | null   |
       | NaN    |
       | 1.5    |
       | false  |
       | 'text' |
   ✔  And no side effects
  Scenario Outline: [23] Sort by a boolean variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                  | bool  |
       | (:B {bool: false}) | false |
       | (:C {bool: false}) | false |
       | (:E {bool: false}) | false |
   ✔  And no side effects
  Scenario Outline: [23] Sort by a boolean variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                  | bool  |
       | (:B {bool: false}) | false |
       | (:C {bool: false}) | false |
       | (:E {bool: false}) | false |
   ✔  And no side effects
  Scenario Outline: [23] Sort by a boolean variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                  | bool  |
       | (:B {bool: false}) | false |
       | (:C {bool: false}) | false |
       | (:E {bool: false}) | false |
   ✔  And no side effects
  Scenario Outline: [24] Sort by a boolean variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                 | bool |
       | (:A {bool: true}) | true |
       | (:D {bool: true}) | true |
   ✔  And no side effects
  Scenario Outline: [24] Sort by a boolean variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                 | bool |
       | (:A {bool: true}) | true |
       | (:D {bool: true}) | true |
   ✔  And no side effects
  Scenario Outline: [25] Sort by an integer variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a               | num |
       | (:D {num: -11}) | -11 |
       | (:B {num: 5})   | 5   |
       | (:A {num: 9})   | 9   |
   ✔  And no side effects
  Scenario Outline: [25] Sort by an integer variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a               | num |
       | (:D {num: -11}) | -11 |
       | (:B {num: 5})   | 5   |
       | (:A {num: 9})   | 9   |
   ✔  And no side effects
  Scenario Outline: [25] Sort by an integer variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a               | num |
       | (:D {num: -11}) | -11 |
       | (:B {num: 5})   | 5   |
       | (:A {num: 9})   | 9   |
   ✔  And no side effects
  Scenario Outline: [26] Sort by an integer variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                | num  |
       | (:E {num: 7054}) | 7054 |
       | (:C {num: 30})   | 30   |
       | (:A {num: 9})    | 9    |
   ✔  And no side effects
  Scenario Outline: [26] Sort by an integer variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                | num  |
       | (:E {num: 7054}) | 7054 |
       | (:C {num: 30})   | 30   |
       | (:A {num: 9})    | 9    |
   ✔  And no side effects
  Scenario Outline: [27] Sort by a float variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                    | num      |
       | (:D {num: -11.2943}) | -11.2943 |
       | (:A {num: 5.025648}) | 5.025648 |
       | (:C {num: 30.94856}) | 30.94856 |
   ✔  And no side effects
  Scenario Outline: [27] Sort by a float variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                    | num      |
       | (:D {num: -11.2943}) | -11.2943 |
       | (:A {num: 5.025648}) | 5.025648 |
       | (:C {num: 30.94856}) | 30.94856 |
   ✔  And no side effects
  Scenario Outline: [27] Sort by a float variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                    | num      |
       | (:D {num: -11.2943}) | -11.2943 |
       | (:A {num: 5.025648}) | 5.025648 |
       | (:C {num: 30.94856}) | 30.94856 |
   ✔  And no side effects
  Scenario Outline: [28] Sort by a float variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                    | num      |
       | (:E {num: 7054.008}) | 7054.008 |
       | (:B {num: 30.94857}) | 30.94857 |
       | (:C {num: 30.94856}) | 30.94856 |
   ✔  And no side effects
  Scenario Outline: [28] Sort by a float variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                    | num      |
       | (:E {num: 7054.008}) | 7054.008 |
       | (:B {num: 30.94857}) | 30.94857 |
       | (:C {num: 30.94856}) | 30.94856 |
   ✔  And no side effects
  Scenario Outline: [29] Sort by a string variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                    | name    |
       | (:E {name: 'amet'})  | 'amet'  |
       | (:C {name: 'dolor'}) | 'dolor' |
       | (:B {name: 'ipsum'}) | 'ipsum' |
   ✔  And no side effects
  Scenario Outline: [29] Sort by a string variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                    | name    |
       | (:E {name: 'amet'})  | 'amet'  |
       | (:C {name: 'dolor'}) | 'dolor' |
       | (:B {name: 'ipsum'}) | 'ipsum' |
   ✔  And no side effects
  Scenario Outline: [29] Sort by a string variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                    | name    |
       | (:E {name: 'amet'})  | 'amet'  |
       | (:C {name: 'dolor'}) | 'dolor' |
       | (:B {name: 'ipsum'}) | 'ipsum' |
   ✔  And no side effects
  Scenario Outline: [30] Sort by a string variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                    | name    |
       | (:D {name: 'sit'})   | 'sit'   |
       | (:A {name: 'lorem'}) | 'lorem' |
       | (:B {name: 'ipsum'}) | 'ipsum' |
   ✔  And no side effects
  Scenario Outline: [30] Sort by a string variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                    | name    |
       | (:D {name: 'sit'})   | 'sit'   |
       | (:A {name: 'lorem'}) | 'lorem' |
       | (:B {name: 'ipsum'}) | 'ipsum' |
   ✔  And no side effects
  Scenario Outline: [31] Sort by a list variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     | list     |
       | (:B {list: [1, 2]})   | [1, 2]   |
       | (:D {list: [1, -20]}) | [1, -20] |
       | (:A {list: [2, -2]})  | [2, -2]  |
   ✔  And no side effects
  Scenario Outline: [31] Sort by a list variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     | list     |
       | (:B {list: [1, 2]})   | [1, 2]   |
       | (:D {list: [1, -20]}) | [1, -20] |
       | (:A {list: [2, -2]})  | [2, -2]  |
   ✔  And no side effects
  Scenario Outline: [31] Sort by a list variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     | list     |
       | (:B {list: [1, 2]})   | [1, 2]   |
       | (:D {list: [1, -20]}) | [1, -20] |
       | (:A {list: [2, -2]})  | [2, -2]  |
   ✔  And no side effects
  Scenario Outline: [32] Sort by a list variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         | list         |
       | (:C {list: [300, 0]})     | [300, 0]     |
       | (:E {list: [2, -2, 100]}) | [2, -2, 100] |
       | (:A {list: [2, -2]})      | [2, -2]      |
   ✔  And no side effects
  Scenario Outline: [32] Sort by a list variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         | list         |
       | (:C {list: [300, 0]})     | [300, 0]     |
       | (:E {list: [2, -2, 100]}) | [2, -2, 100] |
       | (:A {list: [2, -2]})      | [2, -2]      |
   ✔  And no side effects
  Scenario Outline: [33] Sort by a date variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         | date         |
       | (:A {date: '1910-05-06'}) | '1910-05-06' |
       | (:E {date: '1980-10-24'}) | '1980-10-24' |
   ✔  And no side effects
  Scenario Outline: [33] Sort by a date variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         | date         |
       | (:A {date: '1910-05-06'}) | '1910-05-06' |
       | (:E {date: '1980-10-24'}) | '1980-10-24' |
   ✔  And no side effects
  Scenario Outline: [33] Sort by a date variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         | date         |
       | (:A {date: '1910-05-06'}) | '1910-05-06' |
       | (:E {date: '1980-10-24'}) | '1980-10-24' |
   ✔  And no side effects
  Scenario Outline: [34] Sort by a date variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         | date         |
       | (:D {date: '1985-05-06'}) | '1985-05-06' |
       | (:C {date: '1984-10-12'}) | '1984-10-12' |
   ✔  And no side effects
  Scenario Outline: [34] Sort by a date variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         | date         |
       | (:D {date: '1985-05-06'}) | '1985-05-06' |
       | (:C {date: '1984-10-12'}) | '1984-10-12' |
   ✔  And no side effects
  Scenario Outline: [35] Sort by a local time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                 | time                 |
       | (:A {time: '10:35'})              | '10:35'              |
       | (:D {time: '12:30:14.645876123'}) | '12:30:14.645876123' |
       | (:B {time: '12:31:14.645876123'}) | '12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [35] Sort by a local time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                 | time                 |
       | (:A {time: '10:35'})              | '10:35'              |
       | (:D {time: '12:30:14.645876123'}) | '12:30:14.645876123' |
       | (:B {time: '12:31:14.645876123'}) | '12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [35] Sort by a local time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                 | time                 |
       | (:A {time: '10:35'})              | '10:35'              |
       | (:D {time: '12:30:14.645876123'}) | '12:30:14.645876123' |
       | (:B {time: '12:31:14.645876123'}) | '12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [36] Sort by a local time variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                 | time                 |
       | (:E {time: '12:31:15'})           | '12:31:15'           |
       | (:C {time: '12:31:14.645876124'}) | '12:31:14.645876124' |
       | (:B {time: '12:31:14.645876123'}) | '12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [36] Sort by a local time variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                 | time                 |
       | (:E {time: '12:31:15'})           | '12:31:15'           |
       | (:C {time: '12:31:14.645876124'}) | '12:31:14.645876124' |
       | (:B {time: '12:31:14.645876123'}) | '12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [37] Sort by a time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                       | time                       |
       | (:D {time: '12:35:15+05:00'})           | '12:35:15+05:00'           |
       | (:E {time: '12:30:14.645876123+01:01'}) | '12:30:14.645876123+01:01' |
       | (:B {time: '12:31:14.645876123+01:00'}) | '12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario Outline: [37] Sort by a time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                       | time                       |
       | (:D {time: '12:35:15+05:00'})           | '12:35:15+05:00'           |
       | (:E {time: '12:30:14.645876123+01:01'}) | '12:30:14.645876123+01:01' |
       | (:B {time: '12:31:14.645876123+01:00'}) | '12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario Outline: [37] Sort by a time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                       | time                       |
       | (:D {time: '12:35:15+05:00'})           | '12:35:15+05:00'           |
       | (:E {time: '12:30:14.645876123+01:01'}) | '12:30:14.645876123+01:01' |
       | (:B {time: '12:31:14.645876123+01:00'}) | '12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario Outline: [38] Sort by a time variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                       | time                       |
       | (:A {time: '10:35-08:00'})              | '10:35-08:00'              |
       | (:C {time: '12:31:14.645876124+01:00'}) | '12:31:14.645876124+01:00' |
       | (:B {time: '12:31:14.645876123+01:00'}) | '12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario Outline: [38] Sort by a time variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                       | time                       |
       | (:A {time: '10:35-08:00'})              | '10:35-08:00'              |
       | (:C {time: '12:31:14.645876124+01:00'}) | '12:31:14.645876124+01:00' |
       | (:B {time: '12:31:14.645876123+01:00'}) | '12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario Outline: [39] Sort by a local date time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                | datetime                        |
       | (:C {datetime: '0001-01-01T01:01:01.000000001'}) | '0001-01-01T01:01:01.000000001' |
       | (:E {datetime: '1980-12-11T12:31:14'})           | '1980-12-11T12:31:14'           |
       | (:A {datetime: '1984-10-11T12:30:14.000000012'}) | '1984-10-11T12:30:14.000000012' |
   ✔  And no side effects
  Scenario Outline: [39] Sort by a local date time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                | datetime                        |
       | (:C {datetime: '0001-01-01T01:01:01.000000001'}) | '0001-01-01T01:01:01.000000001' |
       | (:E {datetime: '1980-12-11T12:31:14'})           | '1980-12-11T12:31:14'           |
       | (:A {datetime: '1984-10-11T12:30:14.000000012'}) | '1984-10-11T12:30:14.000000012' |
   ✔  And no side effects
  Scenario Outline: [39] Sort by a local date time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                | datetime                        |
       | (:C {datetime: '0001-01-01T01:01:01.000000001'}) | '0001-01-01T01:01:01.000000001' |
       | (:E {datetime: '1980-12-11T12:31:14'})           | '1980-12-11T12:31:14'           |
       | (:A {datetime: '1984-10-11T12:30:14.000000012'}) | '1984-10-11T12:30:14.000000012' |
   ✔  And no side effects
  Scenario Outline: [40] Sort by a local date time variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                | datetime                        |
       | (:D {datetime: '9999-09-09T09:59:59.999999999'}) | '9999-09-09T09:59:59.999999999' |
       | (:B {datetime: '1984-10-11T12:31:14.645876123'}) | '1984-10-11T12:31:14.645876123' |
       | (:A {datetime: '1984-10-11T12:30:14.000000012'}) | '1984-10-11T12:30:14.000000012' |
   ✔  And no side effects
  Scenario Outline: [40] Sort by a local date time variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                | datetime                        |
       | (:D {datetime: '9999-09-09T09:59:59.999999999'}) | '9999-09-09T09:59:59.999999999' |
       | (:B {datetime: '1984-10-11T12:31:14.645876123'}) | '1984-10-11T12:31:14.645876123' |
       | (:A {datetime: '1984-10-11T12:30:14.000000012'}) | '1984-10-11T12:30:14.000000012' |
   ✔  And no side effects
  Scenario Outline: [41] Sort by a date time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                      | datetime                              |
       | (:C {datetime: '0001-01-01T01:01:01.000000001-11:59'}) | '0001-01-01T01:01:01.000000001-11:59' |
       | (:E {datetime: '1980-12-11T12:31:14-11:59'})           | '1980-12-11T12:31:14-11:59'           |
       | (:B {datetime: '1984-10-11T12:31:14.645876123+00:17'}) | '1984-10-11T12:31:14.645876123+00:17' |
   ✔  And no side effects
  Scenario Outline: [41] Sort by a date time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                      | datetime                              |
       | (:C {datetime: '0001-01-01T01:01:01.000000001-11:59'}) | '0001-01-01T01:01:01.000000001-11:59' |
       | (:E {datetime: '1980-12-11T12:31:14-11:59'})           | '1980-12-11T12:31:14-11:59'           |
       | (:B {datetime: '1984-10-11T12:31:14.645876123+00:17'}) | '1984-10-11T12:31:14.645876123+00:17' |
   ✔  And no side effects
  Scenario Outline: [41] Sort by a date time variable projected from a node property in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                      | datetime                              |
       | (:C {datetime: '0001-01-01T01:01:01.000000001-11:59'}) | '0001-01-01T01:01:01.000000001-11:59' |
       | (:E {datetime: '1980-12-11T12:31:14-11:59'})           | '1980-12-11T12:31:14-11:59'           |
       | (:B {datetime: '1984-10-11T12:31:14.645876123+00:17'}) | '1984-10-11T12:31:14.645876123+00:17' |
   ✔  And no side effects
  Scenario Outline: [42] Sort by a date time variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                      | datetime                              |
       | (:D {datetime: '9999-09-09T09:59:59.999999999+11:59'}) | '9999-09-09T09:59:59.999999999+11:59' |
       | (:A {datetime: '1984-10-11T12:30:14.000000012+00:15'}) | '1984-10-11T12:30:14.000000012+00:15' |
       | (:B {datetime: '1984-10-11T12:31:14.645876123+00:17'}) | '1984-10-11T12:31:14.645876123+00:17' |
   ✔  And no side effects
  Scenario Outline: [42] Sort by a date time variable projected from a node property in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                      | datetime                              |
       | (:D {datetime: '9999-09-09T09:59:59.999999999+11:59'}) | '9999-09-09T09:59:59.999999999+11:59' |
       | (:A {datetime: '1984-10-11T12:30:14.000000012+00:15'}) | '1984-10-11T12:30:14.000000012+00:15' |
       | (:B {datetime: '1984-10-11T12:31:14.645876123+00:17'}) | '1984-10-11T12:31:14.645876123+00:17' |
   ✔  And no side effects
  Scenario Outline: [43] Sort by a variable that is only partially orderable on a non-distinct binding table
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 0 |
       | 0 |
   ✔  And no side effects
  Scenario Outline: [43] Sort by a variable that is only partially orderable on a non-distinct binding table
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 2 |
       | 2 |
   ✔  And no side effects
  Scenario Outline: [44] Sort by a variable that is only partially orderable on a non-distinct binding table, but made distinct
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 0 |
   ✔  And no side effects
  Scenario Outline: [44] Sort by a variable that is only partially orderable on a non-distinct binding table, but made distinct
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 2 |
   ✔  And no side effects
  Scenario Outline: [45] Sort order should be consistent with comparisons where comparisons are defined #Example: booleans
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | equal |
       | true  |
   ✔  And no side effects
  Scenario Outline: [45] Sort order should be consistent with comparisons where comparisons are defined #Example: integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | equal |
       | true  |
   ✔  And no side effects
  Scenario Outline: [45] Sort order should be consistent with comparisons where comparisons are defined #Example: floats
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | equal |
       | true  |
   ✔  And no side effects
  Scenario Outline: [45] Sort order should be consistent with comparisons where comparisons are defined #Example: string
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | equal |
       | true  |
   ✔  And no side effects
  Scenario Outline: [45] Sort order should be consistent with comparisons where comparisons are defined #Example: lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | equal |
       | true  |
   ✔  And no side effects
  Scenario Outline: [45] Sort order should be consistent with comparisons where comparisons are defined #Example: dates
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | equal |
       | true  |
   ✔  And no side effects
  Scenario Outline: [45] Sort order should be consistent with comparisons where comparisons are defined #Example: localtimes
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | equal |
       | true  |
   ✔  And no side effects
  Scenario Outline: [45] Sort order should be consistent with comparisons where comparisons are defined #Example: times
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | equal |
       | true  |
   ✔  And no side effects
  Scenario Outline: [45] Sort order should be consistent with comparisons where comparisons are defined #Example: localdatetimes
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | equal |
       | true  |
   ✔  And no side effects
  Scenario Outline: [45] Sort order should be consistent with comparisons where comparisons are defined #Example: datetimes
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | equal |
       | true  |
   ✔  And no side effects
  Scenario Outline: [46] Fail on sorting by an undefined variable #Example: out of scope
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [46] Fail on sorting by an undefined variable #Example: out of scope
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [46] Fail on sorting by an undefined variable #Example: out of scope
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [46] Fail on sorting by an undefined variable #Example: out of scope
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [46] Fail on sorting by an undefined variable #Example: out of scope
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [46] Fail on sorting by an undefined variable #Example: never defined
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [46] Fail on sorting by an undefined variable #Example: never defined
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [46] Fail on sorting by an undefined variable #Example: never defined
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [46] Fail on sorting by an undefined variable #Example: never defined
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [46] Fail on sorting by an undefined variable #Example: never defined
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
Feature: WithOrderBy2 - Order by a single expression
  Scenario Outline: [1] Sort by a boolean expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                              |
       | (:A {bool: true, bool2: true}) |
       | (:D {bool: true, bool2: true}) |
   ✔  And no side effects
  Scenario Outline: [1] Sort by a boolean expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                              |
       | (:A {bool: true, bool2: true}) |
       | (:D {bool: true, bool2: true}) |
   ✔  And no side effects
  Scenario Outline: [1] Sort by a boolean expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                              |
       | (:A {bool: true, bool2: true}) |
       | (:D {bool: true, bool2: true}) |
   ✔  And no side effects
  Scenario Outline: [2] Sort by a boolean expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                |
       | (:B {bool: false, bool2: false}) |
       | (:C {bool: false, bool2: true})  |
       | (:E {bool: true, bool2: false})  |
   ✔  And no side effects
  Scenario Outline: [2] Sort by a boolean expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                |
       | (:B {bool: false, bool2: false}) |
       | (:C {bool: false, bool2: true})  |
       | (:E {bool: true, bool2: false})  |
   ✔  And no side effects
  Scenario Outline: [3] Sort by an integer expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         |
       | (:E {num: 7054, num2: 1}) |
       | (:C {num: 30, num2: 3})   |
       | (:A {num: 9, num2: 5})    |
   ✔  And no side effects
  Scenario Outline: [3] Sort by an integer expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         |
       | (:E {num: 7054, num2: 1}) |
       | (:C {num: 30, num2: 3})   |
       | (:A {num: 9, num2: 5})    |
   ✔  And no side effects
  Scenario Outline: [3] Sort by an integer expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         |
       | (:E {num: 7054, num2: 1}) |
       | (:C {num: 30, num2: 3})   |
       | (:A {num: 9, num2: 5})    |
   ✔  And no side effects
  Scenario Outline: [4] Sort by an integer expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                        |
       | (:D {num: -11, num2: 2}) |
       | (:B {num: 5, num2: 4})   |
       | (:A {num: 9, num2: 5})   |
   ✔  And no side effects
  Scenario Outline: [4] Sort by an integer expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                        |
       | (:D {num: -11, num2: 2}) |
       | (:B {num: 5, num2: 4})   |
       | (:A {num: 9, num2: 5})   |
   ✔  And no side effects
  Scenario Outline: [5] Sort by a float expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                   |
       | (:E {num: 7054.008, num2: 948.841}) |
       | (:B {num: 30.94857, num2: 0.00002}) |
       | (:C {num: 30.94856, num2: 0.00002}) |
   ✔  And no side effects
  Scenario Outline: [5] Sort by a float expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                   |
       | (:E {num: 7054.008, num2: 948.841}) |
       | (:B {num: 30.94857, num2: 0.00002}) |
       | (:C {num: 30.94856, num2: 0.00002}) |
   ✔  And no side effects
  Scenario Outline: [5] Sort by a float expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                   |
       | (:E {num: 7054.008, num2: 948.841}) |
       | (:B {num: 30.94857, num2: 0.00002}) |
       | (:C {num: 30.94856, num2: 0.00002}) |
   ✔  And no side effects
  Scenario Outline: [6] Sort by a float expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                   |
       | (:D {num: -11.2943, num2: -8.5007}) |
       | (:A {num: 5.025648, num2: 1.96357}) |
       | (:C {num: 30.94856, num2: 0.00002}) |
   ✔  And no side effects
  Scenario Outline: [6] Sort by a float expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                   |
       | (:D {num: -11.2943, num2: -8.5007}) |
       | (:A {num: 5.025648, num2: 1.96357}) |
       | (:C {num: 30.94856, num2: 0.00002}) |
   ✔  And no side effects
  Scenario Outline: [7] Sort by a string expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                  |
       | (:A {name: 'lorem', title: 'dr.'}) |
       | (:B {name: 'ipsum', title: 'dr.'}) |
       | (:D {name: 'sit', title: 'dr.'})   |
   ✔  And no side effects
  Scenario Outline: [7] Sort by a string expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                  |
       | (:A {name: 'lorem', title: 'dr.'}) |
       | (:B {name: 'ipsum', title: 'dr.'}) |
       | (:D {name: 'sit', title: 'dr.'})   |
   ✔  And no side effects
  Scenario Outline: [7] Sort by a string expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                  |
       | (:A {name: 'lorem', title: 'dr.'}) |
       | (:B {name: 'ipsum', title: 'dr.'}) |
       | (:D {name: 'sit', title: 'dr.'})   |
   ✔  And no side effects
  Scenario Outline: [8] Sort by a string expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                    |
       | (:C {name: 'dolor', title: 'prof.'}) |
       | (:E {name: 'amet', title: 'prof.'})  |
       | (:D {name: 'sit', title: 'dr.'})     |
   ✔  And no side effects
  Scenario Outline: [8] Sort by a string expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                    |
       | (:C {name: 'dolor', title: 'prof.'}) |
       | (:E {name: 'amet', title: 'prof.'})  |
       | (:D {name: 'sit', title: 'dr.'})     |
   ✔  And no side effects
  Scenario Outline: [9] Sort by a list expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                     |
       | (:C {list: [300, 0], list2: [1, -2]}) |
       | (:B {list: [1, 2], list2: [2, -2]})   |
       | (:A {list: [2, -2], list2: [3, -2]})  |
   ✔  And no side effects
  Scenario Outline: [9] Sort by a list expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                     |
       | (:C {list: [300, 0], list2: [1, -2]}) |
       | (:B {list: [1, 2], list2: [2, -2]})   |
       | (:A {list: [2, -2], list2: [3, -2]})  |
   ✔  And no side effects
  Scenario Outline: [9] Sort by a list expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                     |
       | (:C {list: [300, 0], list2: [1, -2]}) |
       | (:B {list: [1, 2], list2: [2, -2]})   |
       | (:A {list: [2, -2], list2: [3, -2]})  |
   ✔  And no side effects
  Scenario Outline: [10] Sort by a list expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                         |
       | (:E {list: [2, -2, 100], list2: [5, -2]}) |
       | (:D {list: [1, -20], list2: [4, -2]})     |
       | (:A {list: [2, -2], list2: [3, -2]})      |
   ✔  And no side effects
  Scenario Outline: [10] Sort by a list expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                         |
       | (:E {list: [2, -2, 100], list2: [5, -2]}) |
       | (:D {list: [1, -20], list2: [4, -2]})     |
       | (:A {list: [2, -2], list2: [3, -2]})      |
   ✔  And no side effects
  Scenario Outline: [11] Sort by a date expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         |
       | (:A {date: '1910-05-06'}) |
       | (:E {date: '1980-10-24'}) |
   ✔  And no side effects
  Scenario Outline: [11] Sort by a date expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         |
       | (:A {date: '1910-05-06'}) |
       | (:E {date: '1980-10-24'}) |
   ✔  And no side effects
  Scenario Outline: [11] Sort by a date expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         |
       | (:A {date: '1910-05-06'}) |
       | (:E {date: '1980-10-24'}) |
   ✔  And no side effects
  Scenario Outline: [12] Sort by a date expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         |
       | (:D {date: '1985-05-06'}) |
       | (:C {date: '1984-10-12'}) |
   ✔  And no side effects
  Scenario Outline: [12] Sort by a date expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         |
       | (:D {date: '1985-05-06'}) |
       | (:C {date: '1984-10-12'}) |
   ✔  And no side effects
  Scenario Outline: [13] Sort by a local time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                 |
       | (:A {time: '10:35'})              |
       | (:D {time: '12:30:14.645876123'}) |
       | (:B {time: '12:31:14.645876123'}) |
   ✔  And no side effects
  Scenario Outline: [13] Sort by a local time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                 |
       | (:A {time: '10:35'})              |
       | (:D {time: '12:30:14.645876123'}) |
       | (:B {time: '12:31:14.645876123'}) |
   ✔  And no side effects
  Scenario Outline: [13] Sort by a local time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                 |
       | (:A {time: '10:35'})              |
       | (:D {time: '12:30:14.645876123'}) |
       | (:B {time: '12:31:14.645876123'}) |
   ✔  And no side effects
  Scenario Outline: [14] Sort by a local time expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                 |
       | (:E {time: '12:31:15'})           |
       | (:C {time: '12:31:14.645876124'}) |
       | (:B {time: '12:31:14.645876123'}) |
   ✔  And no side effects
  Scenario Outline: [14] Sort by a local time expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                 |
       | (:E {time: '12:31:15'})           |
       | (:C {time: '12:31:14.645876124'}) |
       | (:B {time: '12:31:14.645876123'}) |
   ✔  And no side effects
  Scenario Outline: [15] Sort by a time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                       |
       | (:D {time: '12:35:15+05:00'})           |
       | (:E {time: '12:30:14.645876123+01:01'}) |
       | (:B {time: '12:31:14.645876123+01:00'}) |
   ✔  And no side effects
  Scenario Outline: [15] Sort by a time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                       |
       | (:D {time: '12:35:15+05:00'})           |
       | (:E {time: '12:30:14.645876123+01:01'}) |
       | (:B {time: '12:31:14.645876123+01:00'}) |
   ✔  And no side effects
  Scenario Outline: [15] Sort by a time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                       |
       | (:D {time: '12:35:15+05:00'})           |
       | (:E {time: '12:30:14.645876123+01:01'}) |
       | (:B {time: '12:31:14.645876123+01:00'}) |
   ✔  And no side effects
  Scenario Outline: [16] Sort by a time expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                       |
       | (:A {time: '10:35-08:00'})              |
       | (:C {time: '12:31:14.645876124+01:00'}) |
       | (:B {time: '12:31:14.645876123+01:00'}) |
   ✔  And no side effects
  Scenario Outline: [16] Sort by a time expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                       |
       | (:A {time: '10:35-08:00'})              |
       | (:C {time: '12:31:14.645876124+01:00'}) |
       | (:B {time: '12:31:14.645876123+01:00'}) |
   ✔  And no side effects
  Scenario Outline: [17] Sort by a local date time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                |
       | (:C {datetime: '0001-01-01T01:01:01.000000001'}) |
       | (:E {datetime: '1980-12-11T12:31:14'})           |
       | (:A {datetime: '1984-10-11T12:30:14.000000012'}) |
   ✔  And no side effects
  Scenario Outline: [17] Sort by a local date time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                |
       | (:C {datetime: '0001-01-01T01:01:01.000000001'}) |
       | (:E {datetime: '1980-12-11T12:31:14'})           |
       | (:A {datetime: '1984-10-11T12:30:14.000000012'}) |
   ✔  And no side effects
  Scenario Outline: [17] Sort by a local date time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                |
       | (:C {datetime: '0001-01-01T01:01:01.000000001'}) |
       | (:E {datetime: '1980-12-11T12:31:14'})           |
       | (:A {datetime: '1984-10-11T12:30:14.000000012'}) |
   ✔  And no side effects
  Scenario Outline: [18] Sort by a local date time expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                |
       | (:D {datetime: '9999-09-09T09:59:59.999999999'}) |
       | (:B {datetime: '1984-10-11T12:31:14.645876123'}) |
       | (:A {datetime: '1984-10-11T12:30:14.000000012'}) |
   ✔  And no side effects
  Scenario Outline: [18] Sort by a local date time expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                |
       | (:D {datetime: '9999-09-09T09:59:59.999999999'}) |
       | (:B {datetime: '1984-10-11T12:31:14.645876123'}) |
       | (:A {datetime: '1984-10-11T12:30:14.000000012'}) |
   ✔  And no side effects
  Scenario Outline: [19] Sort by a date time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                      |
       | (:C {datetime: '0001-01-01T01:01:01.000000001-11:59'}) |
       | (:E {datetime: '1980-12-11T12:31:14-11:59'})           |
       | (:B {datetime: '1984-10-11T12:31:14.645876123+00:17'}) |
   ✔  And no side effects
  Scenario Outline: [19] Sort by a date time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                      |
       | (:C {datetime: '0001-01-01T01:01:01.000000001-11:59'}) |
       | (:E {datetime: '1980-12-11T12:31:14-11:59'})           |
       | (:B {datetime: '1984-10-11T12:31:14.645876123+00:17'}) |
   ✔  And no side effects
  Scenario Outline: [19] Sort by a date time expression in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                      |
       | (:C {datetime: '0001-01-01T01:01:01.000000001-11:59'}) |
       | (:E {datetime: '1980-12-11T12:31:14-11:59'})           |
       | (:B {datetime: '1984-10-11T12:31:14.645876123+00:17'}) |
   ✔  And no side effects
  Scenario Outline: [20] Sort by a date time expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                      |
       | (:D {datetime: '9999-09-09T09:59:59.999999999+11:59'}) |
       | (:A {datetime: '1984-10-11T12:30:14.000000012+00:15'}) |
       | (:B {datetime: '1984-10-11T12:31:14.645876123+00:17'}) |
   ✔  And no side effects
  Scenario Outline: [20] Sort by a date time expression in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                                      |
       | (:D {datetime: '9999-09-09T09:59:59.999999999+11:59'}) |
       | (:A {datetime: '1984-10-11T12:30:14.000000012+00:15'}) |
       | (:B {datetime: '1984-10-11T12:31:14.645876123+00:17'}) |
   ✔  And no side effects
  Scenario Outline: [21] Sort by an expression that is only partially orderable on a non-distinct binding table
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name |
       | 'A'  |
       | 'A'  |
   ✔  And no side effects
  Scenario Outline: [21] Sort by an expression that is only partially orderable on a non-distinct binding table
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name |
       | 'C'  |
       | 'C'  |
   ✔  And no side effects
  Scenario Outline: [22] Sort by an expression that is only partially orderable on a non-distinct binding table, but used as a grouping key
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name | cnt |
       | 'A'  | 2   |
   ✔  And no side effects
  Scenario Outline: [22] Sort by an expression that is only partially orderable on a non-distinct binding table, but used as a grouping key
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | name | cnt |
       | 'C'  | 2   |
      Step failed:
      Defined: tests/tck/features/clauses/with-orderBy/WithOrderBy2.feature:691:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["name", "cnt"], values: {"name": String("A"), "cnt": Integer(2)} }
  Scenario Outline: [23] Sort by an expression that is only partially orderable on a non-distinct binding table, but used in parts as a grouping key
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name | cnt |
       | 'A'  | 2   |
   ✔  And no side effects
  Scenario Outline: [23] Sort by an expression that is only partially orderable on a non-distinct binding table, but used in parts as a grouping key
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | name | cnt |
       | 'C'  | 2   |
      Step failed:
      Defined: tests/tck/features/clauses/with-orderBy/WithOrderBy2.feature:719:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["name", "cnt"], values: {"name": String("B"), "cnt": Integer(1)} }
  Scenario Outline: [24] Sort by an expression that is only partially orderable on a non-distinct binding table, but made distinct
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name |
       | 'A'  |
   ✔  And no side effects
  Scenario Outline: [24] Sort by an expression that is only partially orderable on a non-distinct binding table, but made distinct
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name |
       | 'C'  |
   ✔  And no side effects
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
  Scenario Outline: [25] Fail on sorting by an aggregation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
Feature: WithOrderBy3 - Order by multiple expressions
  Scenario Outline: [1] Sort by two expressions, both in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:D {num: -41, bool: true})   |
   ✔  And no side effects
  Scenario Outline: [1] Sort by two expressions, both in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:D {num: -41, bool: true})   |
   ✔  And no side effects
  Scenario Outline: [1] Sort by two expressions, both in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:D {num: -41, bool: true})   |
   ✔  And no side effects
  Scenario Outline: [1] Sort by two expressions, both in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:D {num: -41, bool: true})   |
   ✔  And no side effects
  Scenario Outline: [1] Sort by two expressions, both in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:D {num: -41, bool: true})   |
   ✔  And no side effects
  Scenario Outline: [1] Sort by two expressions, both in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:D {num: -41, bool: true})   |
   ✔  And no side effects
  Scenario Outline: [1] Sort by two expressions, both in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:D {num: -41, bool: true})   |
   ✔  And no side effects
  Scenario Outline: [1] Sort by two expressions, both in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:D {num: -41, bool: true})   |
   ✔  And no side effects
  Scenario Outline: [1] Sort by two expressions, both in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:D {num: -41, bool: true})   |
   ✔  And no side effects
  Scenario Outline: [2] Sort by two expressions, first in ascending order, second in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:A {num: 9, bool: true})     |
   ✔  And no side effects
  Scenario Outline: [2] Sort by two expressions, first in ascending order, second in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:A {num: 9, bool: true})     |
   ✔  And no side effects
  Scenario Outline: [2] Sort by two expressions, first in ascending order, second in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:A {num: 9, bool: true})     |
   ✔  And no side effects
  Scenario Outline: [2] Sort by two expressions, first in ascending order, second in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:A {num: 9, bool: true})     |
   ✔  And no side effects
  Scenario Outline: [2] Sort by two expressions, first in ascending order, second in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:A {num: 9, bool: true})     |
   ✔  And no side effects
  Scenario Outline: [2] Sort by two expressions, first in ascending order, second in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:C {num: -30, bool: false})  |
       | (:B {num: 5, bool: false})    |
       | (:E {num: 7054, bool: false}) |
       | (:A {num: 9, bool: true})     |
   ✔  And no side effects
  Scenario Outline: [3] Sort by two expressions, first in descending order, second in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:D {num: -41, bool: true})  |
       | (:A {num: 9, bool: true})    |
       | (:C {num: -30, bool: false}) |
       | (:B {num: 5, bool: false})   |
   ✔  And no side effects
  Scenario Outline: [3] Sort by two expressions, first in descending order, second in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:D {num: -41, bool: true})  |
       | (:A {num: 9, bool: true})    |
       | (:C {num: -30, bool: false}) |
       | (:B {num: 5, bool: false})   |
   ✔  And no side effects
  Scenario Outline: [3] Sort by two expressions, first in descending order, second in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:D {num: -41, bool: true})  |
       | (:A {num: 9, bool: true})    |
       | (:C {num: -30, bool: false}) |
       | (:B {num: 5, bool: false})   |
   ✔  And no side effects
  Scenario Outline: [3] Sort by two expressions, first in descending order, second in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:D {num: -41, bool: true})  |
       | (:A {num: 9, bool: true})    |
       | (:C {num: -30, bool: false}) |
       | (:B {num: 5, bool: false})   |
   ✔  And no side effects
  Scenario Outline: [3] Sort by two expressions, first in descending order, second in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:D {num: -41, bool: true})  |
       | (:A {num: 9, bool: true})    |
       | (:C {num: -30, bool: false}) |
       | (:B {num: 5, bool: false})   |
   ✔  And no side effects
  Scenario Outline: [3] Sort by two expressions, first in descending order, second in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:D {num: -41, bool: true})  |
       | (:A {num: 9, bool: true})    |
       | (:C {num: -30, bool: false}) |
       | (:B {num: 5, bool: false})   |
   ✔  And no side effects
  Scenario Outline: [4] Sort by two expressions, both in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:A {num: 9, bool: true})     |
       | (:D {num: -41, bool: true})   |
       | (:E {num: 7054, bool: false}) |
       | (:B {num: 5, bool: false})    |
   ✔  And no side effects
  Scenario Outline: [4] Sort by two expressions, both in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:A {num: 9, bool: true})     |
       | (:D {num: -41, bool: true})   |
       | (:E {num: 7054, bool: false}) |
       | (:B {num: 5, bool: false})    |
   ✔  And no side effects
  Scenario Outline: [4] Sort by two expressions, both in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:A {num: 9, bool: true})     |
       | (:D {num: -41, bool: true})   |
       | (:E {num: 7054, bool: false}) |
       | (:B {num: 5, bool: false})    |
   ✔  And no side effects
  Scenario Outline: [4] Sort by two expressions, both in descending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                             |
       | (:A {num: 9, bool: true})     |
       | (:D {num: -41, bool: true})   |
       | (:E {num: 7054, bool: false}) |
       | (:B {num: 5, bool: false})    |
   ✔  And no side effects
  Scenario Outline: [5] An expression without explicit sort direction is sorted in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 2, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [5] An expression without explicit sort direction is sorted in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 2, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [5] An expression without explicit sort direction is sorted in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [5] An expression without explicit sort direction is sorted in ascending order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 1, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'b'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [6] An constant expression does not influence the order determined by other expression before and after the constant expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                     |
       | ({num: 4, text: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [7] The order direction cannot be overwritten
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 1 |
   ✔  And no side effects
  Scenario Outline: [7] The order direction cannot be overwritten
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 1 |
   ✔  And no side effects
  Scenario Outline: [7] The order direction cannot be overwritten
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 1 |
   ✔  And no side effects
  Scenario Outline: [7] The order direction cannot be overwritten
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 1 |
   ✔  And no side effects
  Scenario Outline: [7] The order direction cannot be overwritten
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 1 |
   ✔  And no side effects
  Scenario Outline: [7] The order direction cannot be overwritten
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 3 |
   ✔  And no side effects
  Scenario Outline: [7] The order direction cannot be overwritten
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 3 |
   ✔  And no side effects
  Scenario Outline: [7] The order direction cannot be overwritten
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 3 |
   ✔  And no side effects
  Scenario Outline: [7] The order direction cannot be overwritten
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 3 |
   ✔  And no side effects
  Scenario Outline: [7] The order direction cannot be overwritten
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
       | 3 |
   ✔  And no side effects
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: out of scope
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: never defined
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: mixed
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: mixed
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: mixed
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [8] Fail on sorting by any number of undefined variables in any position #Example: mixed
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
Feature: WithOrderBy4 - Order by in combination with projection and aliasing
  Scenario: [1] Sort by a projected expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                      | sum |
       | (:A {num: 1, num2: 4}) | 5   |
       | (:A {num: 3, num2: 3}) | 6   |
       | (:A {num: 5, num2: 2}) | 7   |

=== TCK Table Cell (Scenario 18) ===
Cell length: 1003
First 80 chars: {data: [{id: '0001', type: 'donut', name: 'Cake', ppu: 0.55, batters: {batter: [
Last 80 chars: ype: 'Glazed'}, {id: '5003', type: 'Chocolate'}, {id: '5004', type: 'Maple'}]}]}

=== Literals8 [18] - Raw Expected Value ===
Length: 1003
Starts with: "{data: [{i"
Ends with: "}]}]}'elpa"
Contains {: true
Contains [: true

=== After Parsing ===
✓ Parsed as Map
  Keys: 1
    - data

=== AFTER PARSING ===
✓ Parsed as Map(1 keys)
   ✔  And no side effects
  Scenario: [2] Sort by an alias of a projected expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                      | sum |
       | (:A {num: 1, num2: 4}) | 5   |
       | (:A {num: 3, num2: 3}) | 6   |
       | (:A {num: 5, num2: 2}) | 7   |
   ✔  And no side effects
  Scenario: [3] Sort by two projected expressions with order priority being different than projection order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                      | sum | mod |
       | (:A {num: 3, num2: 3}) | 6   | 0   |
       | (:A {num: 9, num2: 0}) | 9   | 0   |
       | (:A {num: 1, num2: 4}) | 5   | 1   |
   ✔  And no side effects
  Scenario: [4] Sort by one projected expression and one alias of a projected expression with order priority being different than projection order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                      | sum | mod |
       | (:A {num: 3, num2: 3}) | 6   | 0   |
       | (:A {num: 9, num2: 0}) | 9   | 0   |
       | (:A {num: 1, num2: 4}) | 5   | 1   |
   ✔  And no side effects
  Scenario: [5] Sort by one alias of a projected expression and one projected expression with order priority being different than projection order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                      | sum | mod |
       | (:A {num: 3, num2: 3}) | 6   | 0   |
       | (:A {num: 9, num2: 0}) | 9   | 0   |
       | (:A {num: 1, num2: 4}) | 5   | 1   |
   ✔  And no side effects
  Scenario: [6] Sort by aliases of two projected expressions with order priority being different than projection order
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                      | sum | mod |
       | (:A {num: 3, num2: 3}) | 6   | 0   |
       | (:A {num: 9, num2: 0}) | 9   | 0   |
       | (:A {num: 1, num2: 4}) | 5   | 1   |
   ✔  And no side effects
  Scenario: [7] Sort by an alias of a projected expression where the alias shadows an existing variable
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                      | x |
       | (:A {num: 1, num2: 4}) | 5 |
       | (:A {num: 3, num2: 3}) | 6 |
       | (:A {num: 5, num2: 2}) | 7 |
   ✔  And no side effects
  Scenario: [8] Sort by non-projected existing variable
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                      | mod |
       | (:A {num: 1, num2: 4}) | 1   |
       | (:A {num: 3, num2: 3}) | 0   |
       | (:A {num: 5, num2: 2}) | 2   |
   ✔  And no side effects
  Scenario: [9] Sort by an alias of a projected expression containing the variable shadowed by the alias
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 0 |
       | 0 |
       | 1 |
   ✔  And no side effects
  Scenario: [10] Sort by a non-projected expression containing an alias of a projected expression containing the variable shadowed by the alias
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x |
       | 2 |
       | 1 |
       | 1 |
   ✔  And no side effects
  Scenario: [11] Sort by an aggregate projection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | mod | sum |
       | 2   | 7   |
       | 1   | 13  |
      Step failed:
      Defined: tests/tck/features/clauses/with-orderBy/WithOrderBy4.feature:307:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 1 has no matching expected row: Record { columns: ["mod", "sum"], values: {"mod": Integer(0), "sum": Integer(15)} }
  Scenario: [12] Sort by an aliased aggregate projection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | mod | sum |
       | 2   | 7   |
       | 1   | 13  |
      Step failed:
      Defined: tests/tck/features/clauses/with-orderBy/WithOrderBy4.feature:331:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 1 has no matching expected row: Record { columns: ["mod", "sum"], values: {"mod": Integer(0), "sum": Integer(15)} }
  Scenario: [13] Fail on sorting by a non-projected aggregation on a variable
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario: [14] Fail on sorting by a non-projected aggregation on an expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario: [15] Sort by an aliased aggregate projection does allow subsequent matching
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | rel           |
       | [:T1 {id: 0}] |
       | [:T2 {id: 1}] |
   ✔  And no side effects
  Scenario: [16] Handle constants and parameters inside an order by item which contains an aggregation expression
   ✔  Given an empty graph
   ✔  And parameters are:
       | age | 38 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | avgAge |
       | null   |
   ✔  And no side effects
  Scenario: [17] Handle projected variables inside an order by item which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | age |
   ✔  And no side effects
  Scenario: [18]  Handle projected property accesses inside an order by item which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | age |
   ✔  And no side effects
  Scenario: [19] Fail if not projected variables are used inside an order by item which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario: [20] Fail if more complex expressions, even if projected, are used inside an order by item which contains an aggregation expression
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: AmbiguousAggregationExpression
Feature: WithSkipLimit1 - Skip
  Scenario: [1] Handle dependencies across WITH with SKIP
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b                            |
       | ({name: 'A', num: 0, id: 0}) |
   ✔  And no side effects
  Scenario: [2] Ordering and skipping on aggregate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x    | c |
       | (:X) | 5 |
   ✔  And no side effects
Feature: WithSkipLimit2 - Limit
  Scenario: [1] ORDER BY and LIMIT can be used
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | (:A) |
   ✔  And no side effects
  Scenario: [2] Handle dependencies across WITH with LIMIT
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b                       |
       | (:End {num: 42, id: 0}) |
   ✔  And no side effects
  Scenario: [3] Connected components succeeding WITH with LIMIT
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m    | n    | x    |
       | (:B) | (:A) | (:X) |
   ✔  And no side effects
  Scenario: [4] Ordering and limiting on aggregate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x    | c |
       | (:Y) | 1 |
   ✔  And no side effects
Feature: WithSkipLimit3 - Skip and limit
  Scenario: [1] Get rows in the middle
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n             |
       | ({name: 'C'}) |
       | ({name: 'D'}) |
   ✔  And no side effects
  Scenario: [2] Get rows in the middle by param
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | s | 2 |
       | l | 2 |
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | n             |
       | ({name: 'C'}) |
       | ({name: 'D'}) |
   ✔  And no side effects
  Scenario: [3] Limiting amount of rows when there are fewer left than the LIMIT argument
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | count |
       | 10    |
       | 11    |
       | 12    |
       | 13    |
       | 14    |
       | 15    |
   ✔  And no side effects
Feature: WithWhere1 - Filter single variable
  Scenario: [1] Filter node with property predicate on a single variable with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a             |
       | ({name: 'B'}) |
   ✔  And no side effects
  Scenario: [2] Filter node with property predicate on a single variable with multiple distinct bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name |
       | 'B'  |
   ✔  And no side effects
  Scenario: [3] Filter for an unbound relationship variable
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | other        |
       | (:B {id: 2}) |
   ✔  And no side effects
  Scenario: [4] Filter for an unbound node variable
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | other        |
       | (:B {id: 2}) |
   ✔  And no side effects
Feature: WithWhere2 - Filter multiple variables
  Scenario: [1] Filter nodes with conjunctive two-part property predicate on multi variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d    |
       | (:A) |
       | (:D) |
   ✔  And no side effects
  Scenario: [2] Filter node with conjunctive multi-part property predicates on multi variables with multiple bindings
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | 1 | 0 |
       | 2 | 1 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | out.name   |
       | 'product1' |
   ✔  And no side effects
Feature: WithWhere3 - Equi-Joins on variables
  Scenario: [1] Join between node identities
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    |
       | (:A) | (:A) |
       | (:B) | (:B) |
   ✔  And no side effects
  Scenario: [2] Join between node properties of disconnected nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a            | b            |
       | (:A {id: 2}) | (:B {id: 2}) |
   ✔  And no side effects
  Scenario: [3] Join between node properties of adjacent nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n                       | x                       |
       | (:A {animal: 'monkey'}) | (:C {animal: 'monkey'}) |
       | (:D {animal: 'cow'})    | (:B {animal: 'cow'})    |
   ✔  And no side effects
Feature: WithWhere4 - Non-Equi-Joins on variables
  Scenario: [1] Join nodes on inequality
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    |
       | (:A) | (:B) |
       | (:B) | (:A) |
   ✔  And no side effects
  Scenario: [2] Join with disjunctive multi-part predicates including patterns
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b                   |
       | (:TheLabel {id: 1}) |
   ✔  And no side effects
Feature: WithWhere5 - Filter on predicate resulting in null
  Scenario: [1] Filter out on null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i                         |
       | (:TextNode {var: 'text'}) |
   ✔  And no side effects
  Scenario: [2] Filter out on null if the AND'd predicate evaluates to false
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i                         |
       | (:TextNode {var: 'text'}) |
   ✔  And no side effects
  Scenario: [3] Filter out on null if the AND'd predicate evaluates to true
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i                         |
       | (:TextNode {var: 'text'}) |
   ✔  And no side effects
  Scenario: [4] Do not filter out on null if the OR'd predicate evaluates to true
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i                         |
       | (:TextNode {var: 'text'}) |
       | (:IntNode {var: 0})       |
   ✔  And no side effects
Feature: WithWhere6 - Filter on aggregates
  Scenario: [1] Filter a single aggregate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a             |
       | ({name: 'A'}) |
   ✔  And no side effects
Feature: WithWhere7 - Variable visibility under aliasing
  Scenario: [1] WHERE sees a variable bound before but not after WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name |
       | 'B'  |
   ✔  And no side effects
  Scenario: [2] WHERE sees a variable bound after but not before WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name |
       | 'B'  |
   ✔  And no side effects
  Scenario: [3] WHERE sees both, variable bound before but not after WITH and variable bound after but not before WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name |
       | 'B'  |
       | 'C'  |
   ✔  And no side effects
Feature: Aggregation1 - Count
  Scenario: [1] Count only non-null values
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.name | count(n.num) |
       | 'a'    | 1            |
       | 'b'    | 1            |
   ✔  And no side effects
  Scenario: [2] Counting loop relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And no side effects
Feature: Aggregation2 - Min and Max
  Scenario: [1] `max()` over integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | max(x) |
       | 2      |
   ✔  And no side effects
  Scenario: [2] `min()` over integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | min(x) |
       | -1     |
   ✔  And no side effects
  Scenario: [3] `max()` over floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | max(x) |
       | 2.0    |
   ✔  And no side effects
  Scenario: [4] `min()` over floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | min(x) |
       | 0.5    |
   ✔  And no side effects
  Scenario: [5] `max()` over mixed numeric values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | max(x) |
       | 5      |
   ✔  And no side effects
  Scenario: [6] `min()` over mixed numeric values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | min(x) |
       | 0.1    |
   ✔  And no side effects
  Scenario: [7] `max()` over strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | max(i) |
       | 'b'    |
   ✔  And no side effects
  Scenario: [8] `min()` over strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | min(i) |
       | 'B'    |
   ✔  And no side effects
  Scenario: [9] `max()` over list values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | max(x) |
       | [2, 1] |
   ✔  And no side effects
  Scenario: [10] `min()` over list values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | min(x) |
       | [1]    |
   ✔  And no side effects
  Scenario: [11] `max()` over mixed values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | max(x) |
       | 1      |
   ✔  And no side effects
  Scenario: [12] `min()` over mixed values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | min(x) |
       | [1, 2] |
   ✔  And no side effects
Feature: Aggregation3 - Sum
  Scenario: [1] Sum only non-null values
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.name | sum(n.num) |
       | 'a'    | 75         |
   ✔  And no side effects
  Scenario: [2] No overflow during summation
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum(i)     |
       | 3004498500 |
   ✔  And no side effects
Feature: Aggregation5 - Collect
  Scenario: [1] `collect()` filtering nulls
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n  | collect(x) |
       | () | []         |
   ✔  And no side effects
  Scenario: [2] OPTIONAL MATCH and `collect()` on node property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | a  | b            |
       | [] | [42, 43, 44] |
      Step skipped: tests/tck/features/expressions/aggregation/Aggregation5.feature:64:5
Feature: Aggregation6 - Percentiles
  Scenario Outline: [1] `percentileDisc()`
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | percentile | 0.0 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | 10.0 |
   ✔  And no side effects
  Scenario Outline: [1] `percentileDisc()`
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | percentile | 0.5 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | 20.0 |
   ✔  And no side effects
  Scenario Outline: [1] `percentileDisc()`
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | percentile | 1.0 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | 30.0 |
   ✔  And no side effects
  Scenario Outline: [2] `percentileCont()`
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | percentile | 0.0 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | 10.0 |
   ✔  And no side effects
  Scenario Outline: [2] `percentileCont()`
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | percentile | 0.5 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | 20.0 |
   ✔  And no side effects
  Scenario Outline: [2] `percentileCont()`
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | percentile | 1.0 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p    |
       | 30.0 |
   ✔  And no side effects
  Scenario Outline: [3] `percentileCont()` failing on bad arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | param | 1000 |
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
  Scenario Outline: [3] `percentileCont()` failing on bad arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | param | -1 |
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
  Scenario Outline: [3] `percentileCont()` failing on bad arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | param | 1.1 |
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
  Scenario Outline: [4] `percentileDisc()` failing on bad arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | param | 1000 |
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
  Scenario Outline: [4] `percentileDisc()` failing on bad arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | param | -1 |
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
  Scenario Outline: [4] `percentileDisc()` failing on bad arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  And parameters are:
       | param | 1.1 |
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
  Scenario: [5] `percentileDisc()` failing in more involved query
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
Feature: Aggregation8 - DISTINCT
  Scenario: [1] Distinct on unbound node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(DISTINCT a) |
       | 0                 |
   ✔  And no side effects
  Scenario: [2] Distinct on null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(DISTINCT a.name) |
       | 0                      |
   ✔  And no side effects
  Scenario: [3] Collect distinct nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c  |
       | [] |
   ✔  And no side effects
  Scenario: [4] Collect distinct values mixed with nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c   |
       | [1] |
   ✔  And no side effects
Feature: Boolean1 - And logical operations
  Scenario: [1] Conjunction of two truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | tt   | tf    | tn   | ft    | ff    | fn    | nt   | nf    | nn   |
       | true | false | null | false | false | false | null | false | null |
   ✔  And no side effects
  Scenario: [2] Conjunction of three truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ttt  | ttf   | ttn  | tft   | tff   | tfn   | tnt  | tnf   | tnn  | ftt   | ftf   | ftn   | fft   | fff   | ffn   | fnt   | fnf   | fnn   | ntt  | ntf   | ntn  | nft   | nff   | nfn   | nnt  | nnf   | nnn  |
       | true | false | null | false | false | false | null | false | null | false | false | false | false | false | false | false | false | false | null | false | null | false | false | false | null | false | null |
   ✔  And no side effects
  Scenario: [3] Conjunction of many truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    | tsf   | tsn  | f     | fst   | fsn   | n    | nst  | nsf   | m1    | m2    | m3    |
       | true | false | null | false | false | false | null | null | false | false | false | false |
   ✔  And no side effects
  Scenario: [4] Conjunction is commutative on non-null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | result |
       | true  | true  | true   |
       | true  | false | true   |
       | false | true  | true   |
       | false | false | true   |
   ✔  And no side effects
  Scenario: [5] Conjunction is commutative on null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | result |
       | true  | null  | true   |
       | false | null  | true   |
       | null  | true  | true   |
       | null  | false | true   |
       | null  | null  | true   |
   ✔  And no side effects
  Scenario: [6] Conjunction is associative on non-null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | true  | true   |
       | true  | true  | false | true   |
       | true  | false | true  | true   |
       | true  | false | false | true   |
       | false | true  | true  | true   |
       | false | true  | false | true   |
       | false | false | true  | true   |
       | false | false | false | true   |
   ✔  And no side effects
  Scenario: [7] Conjunction is associative on null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | null  | true   |
       | true  | false | null  | true   |
       | true  | null  | true  | true   |
       | true  | null  | false | true   |
       | true  | null  | null  | true   |
       | false | true  | null  | true   |
       | false | false | null  | true   |
       | false | null  | true  | true   |
       | false | null  | false | true   |
       | false | null  | null  | true   |
       | null  | true  | true  | true   |
       | null  | true  | false | true   |
       | null  | true  | null  | true   |
       | null  | false | true  | true   |
       | null  | false | false | true   |
       | null  | false | null  | true   |
       | null  | null  | true  | true   |
       | null  | null  | false | true   |
       | null  | null  | null  | true   |
   ✔  And no side effects
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on conjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Boolean2 - OR logical operations
  Scenario: [1] Disjunction of two truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | tt   | tf   | tn   | ft   | ff    | fn   | nt   | nf   | nn   |
       | true | true | true | true | false | null | true | null | null |
   ✔  And no side effects
  Scenario: [2] Disjunction of three truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ttt  | ttf  | ttn  | tft  | tff  | tfn  | tnt  | tnf  | tnn  | ftt  | ftf  | ftn  | fft  | fff   | ffn  | fnt  | fnf  | fnn  | ntt  | ntf  | ntn  | nft  | nff  | nfn  | nnt  | nnf  | nnn  |
       | true | true | true | true | true | true | true | true | true | true | true | true | true | false | null | true | null | null | true | true | true | true | null | null | true | null | null |
   ✔  And no side effects
  Scenario: [3] Disjunction of many truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    | tsf  | tsn  | f     | fst  | fsn  | n    | nst  | nsf  | m1   | m2   | m3   |
       | true | true | true | false | true | null | null | true | null | true | true | true |
   ✔  And no side effects
  Scenario: [4] Disjunction is commutative on non-null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | result |
       | true  | true  | true   |
       | true  | false | true   |
       | false | true  | true   |
       | false | false | true   |
   ✔  And no side effects
  Scenario: [5] Disjunction is commutative on null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | result |
       | true  | null  | true   |
       | false | null  | true   |
       | null  | true  | true   |
       | null  | false | true   |
       | null  | null  | true   |
   ✔  And no side effects
  Scenario: [6] Disjunction is associative on non-null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | true  | true   |
       | true  | true  | false | true   |
       | true  | false | true  | true   |
       | true  | false | false | true   |
       | false | true  | true  | true   |
       | false | true  | false | true   |
       | false | false | true  | true   |
       | false | false | false | true   |
   ✔  And no side effects
  Scenario: [7] Disjunction is associative on null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | null  | true   |
       | true  | false | null  | true   |
       | true  | null  | true  | true   |
       | true  | null  | false | true   |
       | true  | null  | null  | true   |
       | false | true  | null  | true   |
       | false | false | null  | true   |
       | false | null  | true  | true   |
       | false | null  | false | true   |
       | false | null  | null  | true   |
       | null  | true  | true  | true   |
       | null  | true  | false | true   |
       | null  | true  | null  | true   |
       | null  | false | true  | true   |
       | null  | false | false | true   |
       | null  | false | null  | true   |
       | null  | null  | true  | true   |
       | null  | null  | false | true   |
       | null  | null  | null  | true   |
   ✔  And no side effects
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Boolean3 - XOR logical operations
  Scenario: [1] Exclusive disjunction of two truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | tt    | tf   | tn   | ft   | ff    | fn   | nt   | nf   | nn   |
       | false | true | null | true | false | null | null | null | null |
   ✔  And no side effects
  Scenario: [2] Exclusive disjunction of three truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ttt  | ttf   | ttn  | tft   | tff  | tfn  | tnt  | tnf  | tnn  | ftt   | ftf  | ftn  | fft  | fff   | ffn  | fnt  | fnf  | fnn  | ntt  | ntf  | ntn  | nft  | nff  | nfn  | nnt  | nnf  | nnn  |
       | true | false | null | false | true | null | null | null | null | false | true | null | true | false | null | null | null | null | null | null | null | null | null | null | null | null | null |
   ✔  And no side effects
  Scenario: [3] Exclusive disjunction of many truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    | tsf   | tsn  | f     | fst  | fsn  | n    | nst  | nsf  | m1   | m2    | m3   |
       | true | false | null | false | true | null | null | null | null | true | false | null |
   ✔  And no side effects
  Scenario: [4] Exclusive disjunction is commutative on non-null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | result |
       | true  | true  | true   |
       | true  | false | true   |
       | false | true  | true   |
       | false | false | true   |
   ✔  And no side effects
  Scenario: [5] Exclusive disjunction is commutative on null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | result |
       | true  | null  | true   |
       | false | null  | true   |
       | null  | true  | true   |
       | null  | false | true   |
       | null  | null  | true   |
   ✔  And no side effects
  Scenario: [6] Exclusive disjunction is associative on non-null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | true  | true   |
       | true  | true  | false | true   |
       | true  | false | true  | true   |
       | true  | false | false | true   |
       | false | true  | true  | true   |
       | false | true  | false | true   |
       | false | false | true  | true   |
       | false | false | false | true   |
   ✔  And no side effects
  Scenario: [7] Exclusive disjunction is associative on null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | null  | true   |
       | true  | false | null  | true   |
       | true  | null  | true  | true   |
       | true  | null  | false | true   |
       | true  | null  | null  | true   |
       | false | true  | null  | true   |
       | false | false | null  | true   |
       | false | null  | true  | true   |
       | false | null  | false | true   |
       | false | null  | null  | true   |
       | null  | true  | true  | true   |
       | null  | true  | false | true   |
       | null  | true  | null  | true   |
       | null  | false | true  | true   |
       | null  | false | false | true   |
       | null  | false | null  | true   |
       | null  | null  | true  | true   |
       | null  | null  | false | true   |
       | null  | null  | null  | true   |
   ✔  And no side effects
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [8] Fail on exclusive disjunction of at least one non-booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Boolean4 - NOT logical operations
  Scenario: [1] Logical negation of truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | nt    | nf   | nn   |
       | false | true | null |
   ✔  And no side effects
  Scenario: [2] Double logical negation of truth values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | nnt  | nnf   | nnn  |
       | true | false | null |
   ✔  And no side effects
  Scenario: [3] NOT and false
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n             |
       | ({name: 'a'}) |
   ✔  And no side effects
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [4] Fail when using NOT on a non-boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Boolean5 - Interop of logical operations
  Scenario: [1] Disjunction is distributive over conjunction on non-null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | true  | true   |
       | true  | true  | false | true   |
       | true  | false | true  | true   |
       | true  | false | false | true   |
       | false | true  | true  | true   |
       | false | true  | false | true   |
       | false | false | true  | true   |
       | false | false | false | true   |
   ✔  And no side effects
  Scenario: [2] Disjunction is distributive over conjunction on null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | null  | true   |
       | true  | false | null  | true   |
       | true  | null  | true  | true   |
       | true  | null  | false | true   |
       | true  | null  | null  | true   |
       | false | true  | null  | true   |
       | false | false | null  | true   |
       | false | null  | true  | true   |
       | false | null  | false | true   |
       | false | null  | null  | true   |
       | null  | true  | true  | true   |
       | null  | true  | false | true   |
       | null  | true  | null  | true   |
       | null  | false | true  | true   |
       | null  | false | false | true   |
       | null  | false | null  | true   |
       | null  | null  | true  | true   |
       | null  | null  | false | true   |
       | null  | null  | null  | true   |
   ✔  And no side effects
  Scenario: [3] Conjunction is distributive over disjunction on non-null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | true  | true   |
       | true  | true  | false | true   |
       | true  | false | true  | true   |
       | true  | false | false | true   |
       | false | true  | true  | true   |
       | false | true  | false | true   |
       | false | false | true  | true   |
       | false | false | false | true   |
   ✔  And no side effects
  Scenario: [4] Conjunction is distributive over disjunction on null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | null  | true   |
       | true  | false | null  | true   |
       | true  | null  | true  | true   |
       | true  | null  | false | true   |
       | true  | null  | null  | true   |
       | false | true  | null  | true   |
       | false | false | null  | true   |
       | false | null  | true  | true   |
       | false | null  | false | true   |
       | false | null  | null  | true   |
       | null  | true  | true  | true   |
       | null  | true  | false | true   |
       | null  | true  | null  | true   |
       | null  | false | true  | true   |
       | null  | false | false | true   |
       | null  | false | null  | true   |
       | null  | null  | true  | true   |
       | null  | null  | false | true   |
       | null  | null  | null  | true   |
   ✔  And no side effects
  Scenario: [5] Conjunction is distributive over exclusive disjunction on non-null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | true  | true   |
       | true  | true  | false | true   |
       | true  | false | true  | true   |
       | true  | false | false | true   |
       | false | true  | true  | true   |
       | false | true  | false | true   |
       | false | false | true  | true   |
       | false | false | false | true   |
   ✔  And no side effects
  Scenario: [6] Conjunction is not distributive over exclusive disjunction on null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     | result |
       | true  | true  | null  | true   |
       | true  | false | null  | true   |
       | true  | null  | true  | true   |
       | true  | null  | false | true   |
       | true  | null  | null  | true   |
       | false | true  | null  | true   |
       | false | false | null  | true   |
       | false | null  | true  | true   |
       | false | null  | false | true   |
       | false | null  | null  | true   |
       | null  | true  | true  | false  |
       | null  | true  | false | true   |
       | null  | true  | null  | true   |
       | null  | false | true  | true   |
       | null  | false | false | true   |
       | null  | false | null  | true   |
       | null  | null  | true  | true   |
       | null  | null  | false | true   |
       | null  | null  | null  | true   |
   ✔  And no side effects
  Scenario: [7] De Morgan's law on non-null: the negation of a disjunction is the conjunction of the negations
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | result |
       | true  | true  | true   |
       | true  | false | true   |
       | false | true  | true   |
       | false | false | true   |
   ✔  And no side effects
  Scenario: [8] De Morgan's law on non-null: the negation of a conjunction is the disjunction of the negations
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | result |
       | true  | true  | true   |
       | true  | false | true   |
       | false | true  | true   |
       | false | false | true   |
   ✔  And no side effects
Feature: Comparison1 - Equality
  Scenario: [1] Number-typed integer comparison
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n         |
       | ({id: 0}) |
   ✔  And no side effects
  Scenario: [2] Number-typed float comparison
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And no side effects
  Scenario: [3] Any-typed string comparison
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And no side effects
  Scenario: [4] Comparing nodes to nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(b) |
       | 1        |
   ✔  And no side effects
  Scenario: [5] Comparing relationships to relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(b) |
       | 1        |
   ✔  And no side effects
  Scenario Outline: [6] Comparing lists to lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Comparing lists to lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [6] Comparing lists to lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Comparing lists to lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Comparing lists to lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [6] Comparing lists to lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [7] Comparing maps to maps
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [8] Equality and inequality of NaN
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | isEqual | isNotEqual |
       | false   | true       |
   ✔  And no side effects
  Scenario Outline: [8] Equality and inequality of NaN
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | isEqual | isNotEqual |
       | false   | true       |
   ✔  And no side effects
  Scenario Outline: [8] Equality and inequality of NaN
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | isEqual | isNotEqual |
       | false   | true       |
   ✔  And no side effects
  Scenario Outline: [8] Equality and inequality of NaN
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | isEqual | isNotEqual |
       | false   | true       |
   ✔  And no side effects
  Scenario Outline: [9] Equality between strings and numbers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [9] Equality between strings and numbers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [9] Equality between strings and numbers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [9] Equality between strings and numbers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [10] Handling inlined equality of large integer
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p.id                |
       | 4611686018427387905 |
   ✔  And no side effects
  Scenario: [11] Handling explicit equality of large integer
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p.id                |
       | 4611686018427387905 |
   ✔  And no side effects
  Scenario: [12] Handling inlined equality of large integer, non-equal values
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p.id |
   ✔  And no side effects
  Scenario: [13] Handling explicit equality of large integer, non-equal values
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p.id |
   ✔  And no side effects
  Scenario: [14] Direction of traversed relationship is not significant for path equality, simple
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p1 = p2 |
       | true    |
   ✔  And no side effects
  Scenario: [15] It is unknown - i.e. null - if a null is equal to a null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | null  |
   ✔  And no side effects
  Scenario: [16] It is unknown - i.e. null - if a null is not equal to a null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | null  |
   ✔  And no side effects
  Scenario: [17] Failing when comparing to an undefined variable
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
Feature: Comparison2 - Half-bounded Range
  Scenario: [1] Comparing strings and integers using > in an AND'd predicate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i.var |
       | 'xx'  |
   ✔  And no side effects
  Scenario: [2] Comparing strings and integers using > in a OR'd predicate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | i.var |
       | 'xx'  |
       | null  |
   ✔  And no side effects
  Scenario Outline: [3] Comparing across types yields null, except numbers
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | lhs | rhs  |
       | 1   | 3.14 |
   ✔  And no side effects
  Scenario Outline: [3] Comparing across types yields null, except numbers
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | lhs | rhs  |
       | 1   | 3.14 |
   ✔  And no side effects
  Scenario Outline: [3] Comparing across types yields null, except numbers
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | lhs  | rhs |
       | 3.14 | 1   |
   ✔  And no side effects
  Scenario Outline: [3] Comparing across types yields null, except numbers
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | lhs  | rhs |
       | 3.14 | 1   |
   ✔  And no side effects
  Scenario Outline: [4] Comparing lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Comparing lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Comparing lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [4] Comparing lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [4] Comparing lists
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] Comparing NaN
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | gt    | gtE   | lt    | ltE   |
       | false | false | false | false |
   ✔  And no side effects
  Scenario Outline: [5] Comparing NaN
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | gt    | gtE   | lt    | ltE   |
       | false | false | false | false |
   ✔  And no side effects
  Scenario Outline: [5] Comparing NaN
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | gt    | gtE   | lt    | ltE   |
       | false | false | false | false |
   ✔  And no side effects
  Scenario Outline: [5] Comparing NaN
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | gt   | gtE  | lt   | ltE  |
       | null | null | null | null |
   ✔  And no side effects
  Scenario Outline: [6] Comparability between numbers and strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Comparability between numbers and strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Comparability between numbers and strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [6] Comparability between numbers and strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
Feature: Comparison3 - Full-Bound Range
  Scenario: [1] Handling numerical ranges 1
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.num |
       | 2     |
   ✔  And no side effects
  Scenario: [2] Handling numerical ranges 2
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.num |
       | 2     |
       | 3     |
   ✔  And no side effects
  Scenario: [3] Handling numerical ranges 3
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.num |
       | 1     |
       | 2     |
   ✔  And no side effects
  Scenario: [4] Handling numerical ranges 4
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.num |
       | 1     |
       | 2     |
       | 3     |
   ✔  And no side effects
  Scenario: [5] Handling string ranges 1
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.name |
       | 'b'    |
   ✔  And no side effects
  Scenario: [6] Handling string ranges 2
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.name |
       | 'b'    |
       | 'c'    |
   ✔  And no side effects
  Scenario: [7] Handling string ranges 3
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.name |
       | 'a'    |
       | 'b'    |
   ✔  And no side effects
  Scenario: [8] Handling string ranges 4
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.name |
       | 'a'    |
       | 'b'    |
       | 'c'    |
   ✔  And no side effects
  Scenario: [9] Handling empty range
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.num |
   ✔  And no side effects
Feature: Comparison4 - Combination of Comparisons
  Scenario: [1] Handling long chains of operators
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | labels(m) |
       | ['B']     |
   ✔  And no side effects
Feature: Conditional1 - Coalesce expression
  Scenario: [1] Run coalesce
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | coalesce(a.title, a.name) |
       | 'CEO'                     |
       | 'Nobody'                  |
   ✔  And no side effects
Feature: Conditional2 - Case Expression
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result      |
       | 'minus ten' |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'zero' |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'one'  |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'five' |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'ten'  |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | 'three thousand' |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | 'something else' |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | 'something else' |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | 'something else' |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | 'something else' |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | 'something else' |
   ✔  And no side effects
  Scenario Outline: [1] Simple cases over integers
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | 'something else' |
   ✔  And no side effects
Feature: ExistentialSubquery1 - Simple existential subquery
  Scenario: [1] Simple subquery without WHERE clause
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n             |
       | (:A {prop:1}) |
   ✔  And no side effects
  Scenario: [2] Simple subquery with WHERE clause
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n             |
       | (:A {prop:1}) |
   ✔  And no side effects
  Scenario: [3] Simple subquery without WHERE clause, not existing pattern
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And no side effects
  Scenario: [4] Simple subquery with WHERE clause, not existing pattern
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
   ✔  And no side effects
Feature: ExistentialSubquery2 - Full existential subquery
  Scenario: [1] Full existential subquery
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n             |
       | (:A {prop:1}) |
   ✔  And no side effects
  Scenario: [2] Full existential subquery with aggregation
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | n             |
       | (:A {prop:1}) |
      Step failed:
      Defined: tests/tck/features/expressions/existentialSubqueries/ExistentialSubquery2.feature:73:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Query failed with error: Some("Execution(Internal(\"count(*) not supported in basic evaluator\"))")
  Scenario: [3] Full existential subquery with update clause should fail
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidClauseComposition
Feature: ExistentialSubquery3 - Nested existential subquery
  Scenario: [1] Nested simple existential subquery
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n             |
       | (:A {prop:1}) |
   ✔  And no side effects
  Scenario: [2] Nested full existential subquery
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n             |
       | (:A {prop:1}) |
   ✔  And no side effects
  Scenario: [3] Nested full existential subquery with pattern predicate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n             |
       | (:A {prop:1}) |
   ✔  And no side effects
Feature: Graph3 - Node labels
  Scenario: [1] Creating node without label
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | labels(node) |
       | []           |
   ✔  And the side effects should be:
       | +nodes | 1 |
  Scenario: [2] Creating node with two labels
   ✔  Given an empty graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | labels(node)   |
       | ['Foo', 'Bar'] |
      Step skipped: tests/tck/features/expressions/graph/Graph3.feature:55:5
  Scenario: [3] Ignore space when creating node with labels
   ✔  Given an empty graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | labels(node)   |
       | ['Foo', 'Bar'] |
      Step skipped: tests/tck/features/expressions/graph/Graph3.feature:71:5
  Scenario: [4] Create node with label in pattern
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | labels(n)  |
       | ['Person'] |
   ✔  And the side effects should be:
       | +nodes         | 2 |
       | +relationships | 1 |
       | +labels        | 2 |
  Scenario: [5] Using `labels()` in return clauses
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | labels(n) |
       | []        |
   ✔  And no side effects
  Scenario: [6] `labels()` should accept type Any
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | l              |
       | ['Foo']        |
       | ['Foo', 'Bar'] |
      Step skipped: tests/tck/features/expressions/graph/Graph3.feature:122:5
  Scenario: [7] `labels()` on null node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | labels(n) | labels(null) |
       | null      | null         |
   ✔  And no side effects
  Scenario: [8] `labels()` failing on a path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario: [9] `labels()` failing on invalid arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/graph/Graph3.feature:165:5
Feature: Graph4 - Edge relationship type
  Scenario: [1] `type()`
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | type(r) |
       | 'T'     |
   ✔  And no side effects
  Scenario: [2] `type()` on two relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | type(r1) | type(r2) |
       | 'T1'     | 'T2'     |
   ✔  And no side effects
  Scenario: [3] `type()` on null relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | type(r) | type(null) |
       | null    | null       |
   ✔  And no side effects
  Scenario: [4] `type()` on mixed null and non-null relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | type(r) |
       | 'T'     |
       | null    |
   ✔  And no side effects
  Scenario: [5] `type()` handling Any type
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | type(list[0]) |
       | 'T'           |
   ✔  And no side effects
  Scenario Outline: [6] `type()` failing on invalid arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/graph/Graph4.feature:128:5
  Scenario Outline: [6] `type()` failing on invalid arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/graph/Graph4.feature:128:5
  Scenario Outline: [6] `type()` failing on invalid arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/graph/Graph4.feature:128:5
  Scenario Outline: [6] `type()` failing on invalid arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/graph/Graph4.feature:128:5
  Scenario Outline: [6] `type()` failing on invalid arguments
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/graph/Graph4.feature:128:5
  Scenario: [7] Failing when using `type()` on a node
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Graph5 - Node and edge label expressions
  Scenario: [1] Single-labels expression on nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a        | result |
       | (:A:B:C) | true   |
       | (:A:B)   | true   |
       | (:A:C)   | false  |
       | (:B:C)   | true   |
       | (:A)     | false  |
       | (:B)     | true   |
       | (:C)     | false  |
       | ()       | false  |
   ✔  And no side effects
  Scenario: [2] Single-labels expression on relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r     | result |
       | [:T1] | false  |
       | [:T2] | true   |
       | [:t2] | false  |
       | [:T3] | false  |
       | [:T4] | false  |
   ✔  And no side effects
  Scenario: [3] Conjunctive labels expression on nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a        | result |
       | (:A:B:C) | true   |
       | (:A:B)   | true   |
       | (:A:C)   | false  |
       | (:B:C)   | false  |
       | (:A)     | false  |
       | (:B)     | false  |
       | (:C)     | false  |
       | ()       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Conjunctive labels expression on nodes with varying order and repeating labels
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a      |
       | (:A:C) |
   ✔  And no side effects
  Scenario Outline: [4] Conjunctive labels expression on nodes with varying order and repeating labels
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a      |
       | (:A:C) |
   ✔  And no side effects
  Scenario Outline: [4] Conjunctive labels expression on nodes with varying order and repeating labels
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a      |
       | (:A:C) |
   ✔  And no side effects
  Scenario Outline: [4] Conjunctive labels expression on nodes with varying order and repeating labels
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a      |
       | (:A:C) |
   ✔  And no side effects
  Scenario Outline: [4] Conjunctive labels expression on nodes with varying order and repeating labels
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a      |
       | (:A:C) |
   ✔  And no side effects
  Scenario: [5] Label expression on null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m:TYPE |
       | null   |
   ✔  And no side effects
Feature: Graph6 - Static property access
  Scenario: [1] Statically access a property of a non-null node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.missing | n.missingToo | n.existing |
       | null      | null         | 42         |
   ✔  And no side effects
  Scenario: [2] Statically access a property of a optional non-null node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.missing | n.missingToo | n.existing |
       | null      | null         | 42         |
   ✔  And no side effects
  Scenario: [3] Statically access a property of a null node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.missing |
       | null      |
   ✔  And no side effects
  Scenario: [4] Statically access a property of a node resulting from an expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | (list[1]).missing | (list[1]).missingToo | (list[1]).existing |
       | null              | null                 | 42                 |
   ✔  And no side effects
  Scenario: [5] Statically access a property of a non-null relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r.missing | r.missingToo | r.existing |
       | null      | null         | 42         |
   ✔  And no side effects
  Scenario: [6] Statically access a property of a optional non-null relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r.missing | r.missingToo | r.existing |
       | null      | null         | 42         |
   ✔  And no side effects
  Scenario: [7] Statically access a property of a null relationship
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r.missing |
       | null      |
   ✔  And no side effects
  Scenario: [8] Statically access a property of a relationship resulting from an expression
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | (list[1]).missing | (list[1]).missingToo | (list[1]).existing |
       | null              | null                 | 42                 |
   ✔  And no side effects
  Scenario Outline: [9] Fail when performing property access on a non-graph element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [9] Fail when performing property access on a non-graph element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [9] Fail when performing property access on a non-graph element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [9] Fail when performing property access on a non-graph element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [9] Fail when performing property access on a non-graph element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [9] Fail when performing property access on a non-graph element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
Feature: Graph7 - Dynamic property access
  Scenario: [1] Execute n['name'] in read queries
   ✔  Given any graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | 'Apa' |
   ✔  And no side effects
  Scenario: [2] Execute n['name'] in update queries
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | 'Apa' |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
  Scenario: [3] Use dynamic property lookup based on parameters when there is lhs type information
   ✔  Given any graph
   ✔  And parameters are:
       | idx | 'name' |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | 'Apa' |
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
Feature: Graph8 - Property keys function
  Scenario: [1] Using `keys()` on a single node, non-empty result
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | theProps  |
       | 'name'    |
       | 'surname' |
   ✔  And no side effects
  Scenario: [2] Using `keys()` on multiple nodes, non-empty result
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | theProps       |
       | 'name'         |
       | 'surname'      |
       | 'otherName'    |
       | 'otherSurname' |
   ✔  And no side effects
  Scenario: [3] Using `keys()` on a single node, empty result
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | theProps |
   ✔  And no side effects
  Scenario: [4] Using `keys()` on an optionally matched node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | theProps |
   ✔  And no side effects
  Scenario: [5] Using `keys()` on a relationship, non-empty result
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | theProps |
       | 'status' |
       | 'year'   |
   ✔  And no side effects
  Scenario: [6] Using `keys()` on a relationship, empty result
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | theProps |
   ✔  And no side effects
  Scenario: [7] Using `keys()` on an optionally matched relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | theProps |
   ✔  And no side effects
  Scenario: [8] Using `keys()` and `IN` to check property existence
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b     | c     |
       | true | false | false |
   ✔  And no side effects
Feature: Graph9 - Retrieve all properties as a property map
  Scenario: [1] `properties()` on a node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m                             |
       | {name: 'Popeye', level: 9001} |
   ✔  And no side effects
  Scenario: [2] `properties()` on a relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m                             |
       | {name: 'Popeye', level: 9001} |
   ✔  And no side effects
  Scenario: [3] `properties()` on null
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | properties(n) | properties(r) | properties(null) |
       | null          | null          | null             |
   ✔  And no side effects
  Scenario: [4] `properties()` on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m                             |
       | {name: 'Popeye', level: 9001} |
   ✔  And no side effects
  Scenario: [5] `properties()` failing on an integer literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario: [6] `properties()` failing on a string literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario: [7] `properties()` failing on a list of booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: List1 - Dynamic Element Access
  Scenario: [1] Indexing into literal list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | 1     |
   ✔  And no side effects
  Scenario: [2] Indexing into nested literal lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | [[1]][0][0] |
       | 1           |
   ✔  And no side effects
  Scenario: [3] Use list lookup based on parameters when there is no type information
   ✔  Given any graph
   ✔  And parameters are:
       | expr | ['Apa'] |
       | idx  | 0       |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | 'Apa' |
   ✔  And no side effects
  Scenario: [4] Use list lookup based on parameters when there is lhs type information
   ✔  Given any graph
   ✔  And parameters are:
       | idx | 0 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | 'Apa' |
   ✔  And no side effects
  Scenario: [5] Use list lookup based on parameters when there is rhs type information
   ✔  Given any graph
   ✔  And parameters are:
       | expr | ['Apa'] |
       | idx  | 0       |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | 'Apa' |
   ✔  And no side effects
  Scenario Outline: [6] Fail when indexing a non-list #Example: boolean
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: InvalidArgumentType
      Step skipped: tests/tck/features/expressions/list/List1.feature:107:5
  Scenario Outline: [6] Fail when indexing a non-list #Example: integer
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: InvalidArgumentType
      Step skipped: tests/tck/features/expressions/list/List1.feature:107:5
  Scenario Outline: [6] Fail when indexing a non-list #Example: float
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: InvalidArgumentType
      Step skipped: tests/tck/features/expressions/list/List1.feature:107:5
  Scenario Outline: [6] Fail when indexing a non-list #Example: string
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: InvalidArgumentType
      Step skipped: tests/tck/features/expressions/list/List1.feature:107:5
  Scenario Outline: [7] Fail when indexing a non-list given by a parameter #Example: boolean
   ✔  Given any graph
   ✔  And parameters are:
       | expr | true |
       | idx  | 0    |
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:126:5
  Scenario Outline: [7] Fail when indexing a non-list given by a parameter #Example: integer
   ✔  Given any graph
   ✔  And parameters are:
       | expr | 123 |
       | idx  | 0   |
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:126:5
  Scenario Outline: [7] Fail when indexing a non-list given by a parameter #Example: float
   ✔  Given any graph
   ✔  And parameters are:
       | expr | 4.7 |
       | idx  | 0   |
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:126:5
  Scenario Outline: [7] Fail when indexing a non-list given by a parameter #Example: string
   ✔  Given any graph
   ✔  And parameters are:
       | expr | '1' |
       | idx  | 0   |
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:126:5
  Scenario Outline: [8] Fail when indexing with a non-integer #Example: boolean
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:142:5
  Scenario Outline: [8] Fail when indexing with a non-integer #Example: float
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:142:5
  Scenario Outline: [8] Fail when indexing with a non-integer #Example: string
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:142:5
  Scenario Outline: [8] Fail when indexing with a non-integer #Example: list
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:142:5
  Scenario Outline: [8] Fail when indexing with a non-integer #Example: map
   ✔  Given any graph
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:142:5
  Scenario Outline: [9] Fail when indexing with a non-integer given by a parameter #Example: boolean
   ✔  Given any graph
   ✔  And parameters are:
       | expr | ['Apa'] |
       | idx  | true    |
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:162:5
  Scenario Outline: [9] Fail when indexing with a non-integer given by a parameter #Example: float
   ✔  Given any graph
   ✔  And parameters are:
       | expr | ['Apa'] |
       | idx  | 4.7     |
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:162:5
  Scenario Outline: [9] Fail when indexing with a non-integer given by a parameter #Example: string
   ✔  Given any graph
   ✔  And parameters are:
       | expr | ['Apa'] |
       | idx  | '1'     |
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:162:5
  Scenario Outline: [9] Fail when indexing with a non-integer given by a parameter #Example: list
   ✔  Given any graph
   ✔  And parameters are:
       | expr | ['Apa'] |
       | idx  | [1]     |
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:162:5
  Scenario Outline: [9] Fail when indexing with a non-integer given by a parameter #Example: map
   ✔  Given any graph
   ✔  And parameters are:
       | expr | ['Apa'] |
       | idx  | {x: 3}  |
   ✔  When executing query:
   ?  Then a TypeError should be raised at any time: *
      Step skipped: tests/tck/features/expressions/list/List1.feature:162:5
Feature: List11 - Create a list from a range
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                  |
       | [-1236, -1235, -1234] |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list    |
       | [-1234] |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                              |
       | [-10, -9, -8, -7, -6, -5, -4, -3] |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                                         |
       | [-10, -9, -8, -7, -6, -5, -4, -3, -2, -1, 0] |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list    |
       | [-1, 0] |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list |
       | []   |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list |
       | []   |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list       |
       | [-1, 0, 1] |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list |
       | [0]  |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list   |
       | [0, 1] |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                               |
       | [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list             |
       | [6, 7, 8, 9, 10] |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list   |
       | [1234] |
   ✔  And no side effects
  Scenario Outline: [1] Create list from `range()` with default step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list               |
       | [1234, 1235, 1236] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                     |
       | [1381, 83, -1215, -2513] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list       |
       | [0, -1298] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                      |
       | [10, 7, 4, 1, -2, -5, -8] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list            |
       | [0, -3, -6, -9] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                                              |
       | [0, -2, -4, -6, -8, -10, -12, -14, -16, -18, -20] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                                         |
       | [0, -1, -2, -3, -4, -5, -6, -7, -8, -9, -10] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list    |
       | [0, -1] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                  |
       | [-1236, -1235, -1234] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                                         |
       | [-10, -9, -8, -7, -6, -5, -4, -3, -2, -1, 0] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list    |
       | [-1, 0] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list |
       | []   |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list |
       | []   |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list |
       | []   |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list |
       | []   |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list |
       | [0]  |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list |
       | [0]  |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list |
       | [0]  |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list   |
       | [0, 1] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                               |
       | [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list             |
       | [6, 7, 8, 9, 10] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list   |
       | [1234] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list               |
       | [1234, 1235, 1236] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list              |
       | [-10, -7, -4, -1] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                       |
       | [-10, -7, -4, -1, 2, 5, 8] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list          |
       | [-2000, -702] |
   ✔  And no side effects
  Scenario Outline: [2] Create list from `range()` with explicitly given step
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                      |
       | [-3412, -2114, -816, 482] |
   ✔  And no side effects
  Scenario: [3] Create an empty list if range direction and step direction are inconsistent
   ✔  Given any graph
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | okay |
       | true |
      Step failed:
      Defined: tests/tck/features/expressions/list/List11.feature:112:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Query failed with error: Some("Execution(UnknownFunction(\"collect\"))")
  Scenario Outline: [4] Fail on invalid arguments for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
  Scenario Outline: [4] Fail on invalid arguments for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
  Scenario Outline: [4] Fail on invalid arguments for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
  Scenario Outline: [4] Fail on invalid arguments for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: NumberOutOfRange
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
  Scenario Outline: [5] Fail on invalid argument types for `range()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a ArgumentError should be raised at runtime: InvalidArgumentType
Feature: List12 - List Comprehension
  Scenario: [1] Collect and extract using a list comprehension
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.name    | oldNames     |
       | 'newName' | ['original'] |
   ✔  And the side effects should be:
       | +properties | 1 |
       | -properties | 1 |
  Scenario: [2] Collect and filter using a list comprehension
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.name    | size(noopFiltered) |
       | 'newName' | 1                  |
   ✔  And the side effects should be:
       | +properties | 1 |
       | -properties | 1 |
  Scenario: [3] Size of list comprehension
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | cn |
       | 0  |
   ✔  And no side effects
  Scenario: [4] Returning a list comprehension
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p            |
       | [(:A), (:A)] |
   ✔  And no side effects
  Scenario: [5] Using a list comprehension in a WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | p            | c |
       | [(:A), (:A)] | 2 |
   ✔  And no side effects
  Scenario: [6] Using a list comprehension in a WHERE
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b    |
       | (:C) |
   ✔  And no side effects
  Scenario: [7] Fail when using aggregation in list comprehension
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidAggregation
Feature: List2 - List Slicing
  Scenario: [1] List slice
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r      |
       | [2, 3] |
   ✔  And no side effects
  Scenario: [2] List slice with implicit end
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r      |
       | [2, 3] |
   ✔  And no side effects
  Scenario: [3] List slice with implicit start
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r      |
       | [1, 2] |
   ✔  And no side effects
  Scenario: [4] List slice with singleton range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r   |
       | [1] |
   ✔  And no side effects
  Scenario: [5] List slice with empty range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r  |
       | [] |
   ✔  And no side effects
  Scenario: [6] List slice with negative range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r      |
       | [1, 2] |
   ✔  And no side effects
  Scenario: [7] List slice with invalid range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r  |
       | [] |
   ✔  And no side effects
  Scenario: [8] List slice with exceeding range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r         |
       | [1, 2, 3] |
   ✔  And no side effects
  Scenario Outline: [9] List slice with null range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | null |
   ✔  And no side effects
  Scenario Outline: [9] List slice with null range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | null |
   ✔  And no side effects
  Scenario Outline: [9] List slice with null range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | null |
   ✔  And no side effects
  Scenario Outline: [9] List slice with null range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | null |
   ✔  And no side effects
  Scenario Outline: [9] List slice with null range
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | null |
   ✔  And no side effects
  Scenario: [10] List slice with parameterised range
   ✔  Given any graph
   ✔  And parameters are:
       | from | 1 |
       | to   | 3 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r      |
       | [2, 3] |
   ✔  And no side effects
  Scenario: [11] List slice with parameterised invalid range
   ✔  Given any graph
   ✔  And parameters are:
       | from | 3 |
       | to   | 1 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r  |
       | [] |
   ✔  And no side effects
Feature: List3 - List Equality
  Scenario: [1] Equality between list and literal should return false
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [2] Equality of lists of different length should return false despite nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [3] Equality between different lists with null should return false
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [4] Equality between almost equal lists with null should return null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | null |
   ✔  And no side effects
  Scenario: [5] Equality of nested lists of different length should return false despite nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [6] Equality between different nested lists with null should return false
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [7] Equality between almost equal nested lists with null should return null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | null |
   ✔  And no side effects
Feature: List4 - List Concatenation
  Scenario: [1] Concatenating lists of same type
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | foo                |
       | [1, 10, 100, 4, 5] |
   ✔  And no side effects
  Scenario: [2] Concatenating a list with a scalar of same type
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | foo                  |
       | [false, true, false] |
   ✔  And no side effects
Feature: List5 - List Membership Validation - IN Operator
  Scenario: [1] IN should work with nested list subscripting
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | true |
   ✔  And no side effects
  Scenario: [2] IN should work with nested literal list subscripting
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r    |
       | true |
   ✔  And no side effects
  Scenario: [3] IN should work with list slices
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r     |
       | false |
   ✔  And no side effects
  Scenario: [4] IN should work with literal list slices
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | r     |
       | false |
   ✔  And no side effects
  Scenario: [5] IN should return false when matching a number with a string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [6] IN should return false when matching a number with a string - list version
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [7] IN should return false when types of LHS and RHS don't match - singleton list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [8] IN should return false when types of LHS and RHS don't match - list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [9] IN should return true when types of LHS and RHS match - singleton list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [10] IN should return true when types of LHS and RHS match - list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [11] IN should return false when order of elements in LHS list and RHS list don't match
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [12] IN with different length lists should return false
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [13] IN should return false when matching a list with a nested list with same elements
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [14] IN should return true when both LHS and RHS contain nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [15] IN should return true when both LHS and RHS contain a nested list alongside a scalar element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [16] IN should return true when LHS and RHS contain a nested list - singleton version
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [17] IN should return true when LHS and RHS contain a nested list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [18] IN should return false when LHS contains a nested list and type mismatch on RHS - singleton version
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [19] IN should return false when LHS contains a nested list and type mismatch on RHS
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [20] IN should return null if LHS and RHS are null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | null |
   ✔  And no side effects
  Scenario: [21] IN should return null if LHS and RHS are null - list version
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | null |
   ✔  And no side effects
  Scenario: [22] IN should return null when LHS and RHS both ultimately contain null, even if LHS and RHS are of different types (nested list and flat list)
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | null |
   ✔  And no side effects
  Scenario: [23] IN with different length lists should return false despite nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [24] IN should return true if match despite nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [25] IN should return null if comparison with null is required
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | null |
   ✔  And no side effects
  Scenario: [26] IN should return true if correct list found despite other lists having nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [27] IN should return true if correct list found despite null being another element within containing list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [28] IN should return false if no match can be found, despite nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [29] IN should return null if comparison with null is required, list version
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | null |
   ✔  And no side effects
  Scenario: [30] IN should return false if different length lists compared, even if the extra element is null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [31] IN should return null when comparing two so-called identical lists where one element is null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | null |
   ✔  And no side effects
  Scenario: [32] IN should return true with previous null match, list version
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [33] IN should return false if different length lists with nested elements compared, even if the extra element is null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [34] IN should return null if comparison with null is required, list version 2
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | null |
   ✔  And no side effects
  Scenario: [35] IN should work with an empty list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [36] IN should return false for the empty list if the LHS and RHS types differ
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [37] IN should work with an empty list in the presence of other list elements: matching
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [38] IN should work with an empty list in the presence of other list elements: not matching
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res   |
       | false |
   ✔  And no side effects
  Scenario: [39] IN should work with an empty list when comparing nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario: [40] IN should return null if comparison with null is required for empty list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | null |
   ✔  And no side effects
  Scenario: [41] IN should return true when LHS and RHS contain nested list with multiple empty lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | res  |
       | true |
   ✔  And no side effects
  Scenario Outline: [42] Failing when using IN on a non-list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [42] Failing when using IN on a non-list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [42] Failing when using IN on a non-list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [42] Failing when using IN on a non-list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [42] Failing when using IN on a non-list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: List6 - List size
  Scenario: [1] Return list size
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n |
       | 3 |
   ✔  And no side effects
  Scenario: [2] Setting and returning the size of a list property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | size(n.numbers) |
       | 3               |
   ✔  And the side effects should be:
       | +properties | 1 |
  Scenario: [3] Concatenating and returning the size of literal lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | l |
       | 3 |
   ✔  And no side effects
  Scenario: [4] `size()` on null list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | size(l) | size(null) |
       | null    | null       |
   ✔  And no side effects
  Scenario: [5] Fail for `size()` on paths
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [6] Fail for `size()` on pattern predicates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario Outline: [6] Fail for `size()` on pattern predicates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario Outline: [6] Fail for `size()` on pattern predicates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario Outline: [6] Fail for `size()` on pattern predicates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario Outline: [6] Fail for `size()` on pattern predicates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario Outline: [6] Fail for `size()` on pattern predicates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario Outline: [6] Fail for `size()` on pattern predicates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario Outline: [6] Fail for `size()` on pattern predicates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [7] Using size of pattern comprehension to test existence
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n              | b     |
       | (:X {num: 42}) | true  |
       | (:X {num: 43}) | false |
   ✔  And no side effects
  Scenario: [8] Get node degree via size of pattern comprehension
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | length |
       | 3      |
   ✔  And no side effects
  Scenario: [9] Get node degree via size of pattern comprehension that specifies a relationship type
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | length |
       | 3      |
   ✔  And no side effects
  Scenario: [10] Get node degree via size of pattern comprehension that specifies multiple relationship types
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | length |
       | 4      |
   ✔  And no side effects
Feature: List9 - List Tail
  Scenario: [1] Returning nested expressions based on list property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | tail(tail(n.array)) |
       | [3, 4, 5]           |
   ✔  And the side effects should be:
       | +properties | 1 |
Feature: Literals1 - Boolean and Null
  Scenario: [1] Return a boolean true lower case
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | true    |
   ✔  And no side effects
  Scenario: [2] Return a boolean true upper case
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | true    |
   ✔  And no side effects
  Scenario: [3] Return a boolean false lower case
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | false   |
   ✔  And no side effects
  Scenario: [4] Return a boolean false upper case
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | false   |
   ✔  And no side effects
  Scenario: [5] Return null lower case
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | null    |
   ✔  And no side effects
  Scenario: [6] Return null upper case
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | null    |
   ✔  And no side effects
Feature: Literals2 - Decimal integer
  Scenario: [1] Return a short positive integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 1       |
   ✔  And no side effects
  Scenario: [2] Return a long positive integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal   |
       | 372036854 |
   ✔  And no side effects
  Scenario: [3] Return the largest integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal             |
       | 9223372036854775807 |
   ✔  And no side effects
  Scenario: [4] Return a positive zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0       |
   ✔  And no side effects
  Scenario: [5] Return a negative zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0       |
   ✔  And no side effects
  Scenario: [6] Return a short negative integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | -1      |
   ✔  And no side effects
  Scenario: [7] Return a long negative integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal    |
       | -372036854 |
   ✔  And no side effects
  Scenario: [8] Return the smallest integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal              |
       | -9223372036854775808 |
   ✔  And no side effects
  Scenario: [9] Fail on a too large integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: IntegerOverflow
  Scenario: [10] Fail on a too small integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: IntegerOverflow
  Scenario: [11] Fail on an integer containing a alphabetic character
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidNumberLiteral
  Scenario: [12] Fail on an integer containing a invalid symbol character
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
Feature: Literals3 - Hexadecimal integer
  Scenario: [1] Return a short positive hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 1       |
   ✔  And no side effects
  Scenario: [2] Return a long positive hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal   |
       | 372036854 |
   ✔  And no side effects
  Scenario: [3] Return the largest hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal             |
       | 9223372036854775807 |
   ✔  And no side effects
  Scenario: [4] Return a positive hexadecimal zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0       |
   ✔  And no side effects
  Scenario: [5] Return a negative hexadecimal zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0       |
   ✔  And no side effects
  Scenario: [6] Return a short negative hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | -1      |
   ✔  And no side effects
  Scenario: [7] Return a long negative hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal    |
       | -372036854 |
   ✔  And no side effects
  Scenario: [8] Return the smallest hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal              |
       | -9223372036854775808 |
   ✔  And no side effects
  Scenario: [9] Return a lower case hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal         |
       | 460367961908983 |
   ✔  And no side effects
  Scenario: [10] Return a upper case hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal         |
       | 460367961908983 |
   ✔  And no side effects
  Scenario: [11] Return a mixed case hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal         |
       | 460367961908983 |
   ✔  And no side effects
  Scenario: [12] Fail on an incomplete hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidNumberLiteral
  Scenario: [13] Fail on an hexadecimal literal containing a lower case invalid alphanumeric character
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidNumberLiteral
  Scenario: [14] Fail on an hexadecimal literal containing a upper case invalid alphanumeric character
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidNumberLiteral
  Scenario: [16] Fail on a too large hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: IntegerOverflow
  Scenario: [17] Fail on a too small hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: IntegerOverflow
Feature: Literals4 - Octal integer
  Scenario: [1] Return a short positive octal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 1       |
   ✔  And no side effects
  Scenario: [2] Return a long positive octal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal   |
       | 372036854 |
   ✔  And no side effects
  Scenario: [3] Return the largest octal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal             |
       | 9223372036854775807 |
   ✔  And no side effects
  Scenario: [4] Return a positive octal zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0       |
   ✔  And no side effects
  Scenario: [5] Return a negative octal zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0       |
   ✔  And no side effects
  Scenario: [6] Return a short negative octal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | -1      |
   ✔  And no side effects
  Scenario: [7] Return a long negative octal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal    |
       | -372036854 |
   ✔  And no side effects
  Scenario: [8] Return the smallest octal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal              |
       | -9223372036854775808 |
   ✔  And no side effects
  Scenario: [9] Fail on a too large octal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: IntegerOverflow
  Scenario: [10] Fail on a too small octal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: IntegerOverflow
Feature: Literals5 - Float
  Scenario: [1] Return a short positive float
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 1.0     |
   ✔  And no side effects
  Scenario: [2] Return a short positive float without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0.1     |
   ✔  And no side effects
  Scenario: [3] Return a long positive float
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal            |
       | 3985764.3405892686 |
   ✔  And no side effects
  Scenario: [4] Return a long positive float without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal      |
       | 0.3405892687 |
   ✔  And no side effects
  Scenario: [5] Return a very long positive float
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                |
       | 1.2635418652381264e305 |
   ✔  And no side effects
  Scenario: [6] Return a very long positive float without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 1e-305  |
   ✔  And no side effects
  Scenario: [7] Return a positive zero float
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0.0     |
   ✔  And no side effects
  Scenario: [8] Return a positive zero float without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0.0     |
   ✔  And no side effects
  Scenario: [9] Return a negative zero float
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0.0     |
   ✔  And no side effects
  Scenario: [10] Return a negative zero float without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0.0     |
   ✔  And no side effects
  Scenario: [11] Return a very long negative float
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                 |
       | -1.2635418652381264e305 |
   ✔  And no side effects
  Scenario: [12] Return a very long negative float without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | -1e-305 |
   ✔  And no side effects
  Scenario: [13] Return a positive float with positive lower case exponent
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal      |
       | 1000000000.0 |
   ✔  And no side effects
  Scenario: [14] Return a positive float with positive upper case exponent
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal      |
       | 1000000000.0 |
   ✔  And no side effects
  Scenario: [15] Return a positive float with positive lower case exponent without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal     |
       | 100000000.0 |
   ✔  And no side effects
  Scenario: [16] Return a positive float with negative lower case exponent
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 0.00001 |
   ✔  And no side effects
  Scenario: [17] Return a positive float with negative lower case exponent without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal  |
       | 0.000001 |
   ✔  And no side effects
  Scenario: [18] Return a positive float with negative upper case exponent without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal  |
       | 0.000001 |
   ✔  And no side effects
  Scenario: [19] Return a negative float in with positive lower case exponent
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal       |
       | -1000000000.0 |
   ✔  And no side effects
  Scenario: [20] Return a negative float in with positive upper case exponent
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal       |
       | -1000000000.0 |
   ✔  And no side effects
  Scenario: [21] Return a negative float with positive lower case exponent without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal      |
       | -100000000.0 |
   ✔  And no side effects
  Scenario: [22] Return a negative float with negative lower case exponent
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal  |
       | -0.00001 |
   ✔  And no side effects
  Scenario: [23] Return a negative float with negative lower case exponent without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal   |
       | -0.000001 |
   ✔  And no side effects
  Scenario: [24] Return a negative float with negative upper case exponent without integer digits
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal   |
       | -0.000001 |
   ✔  And no side effects
  Scenario: [25] Return a positive float with one integer digit and maximum positive exponent
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 1e308   |
   ✔  And no side effects
  Scenario: [26] Return a positive float with nine integer digit and maximum positive exponent
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal        |
       | 1.23456789e308 |
   ✔  And no side effects
  Scenario: [27] Fail when float value is too large
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: FloatingPointOverflow
Feature: Literals6 - String
  Scenario: [1] Return a single-quoted empty string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | ''      |
   ✔  And no side effects
  Scenario: [2] Return a single-quoted string with one character
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 'a'     |
   ✔  And no side effects
  Scenario: [3] Return a single-quoted string with uft-8 characters
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal             |
       | '🧐🍌❖⋙⚐'             |
   ✔  And no side effects
  Scenario: [4] Return a single-quoted string with escaped single-quoted
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | '\''    |
   ✔  And no side effects
  Scenario: [5] Return a single-quoted string with escaped characters
   ✔  Given any graph
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | literal                      |
       | 'a\\\\bcn5t\'"\\\\//\\\\"\'' |
      Step failed:
      Defined: tests/tck/features/expressions/literals/Literals6.feature:85:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["literal"], values: {"literal": String("a\\bcn5t'\"\\//\\\"'")} }
  Scenario: [6] Return a single-quoted string with 100 characters
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                                                                                |
       | 'zvhg02LrjXbeIWUue4CzFT1baQ5ZA uP0ur4suuufFWZu3MGLlMUDYdhya1WcV8GcpEa4Pi03YjPieg2hJY3rt4OAQIeBKhpasUd' |
   ✔  And no side effects
  Scenario: [7] Return a single-quoted string with 1000 characters
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
       | '92WeD0wBWj GWB1Y pUd6ZiCalZR5VJzIxXt6C74 4bfhdEAkXIHccJ4Avce2aWXTBj v22FvYQ4F0R GfPsbTyQYaL6DEHMbKR HlnP3BrpNBSO427Tsayra 950dNriiiRPbfLhV5oNHZl1Lbs44oAl40hU4LTkZkzIzNhwDtnOunSXwHH4FWpoqSP7B8VHz88z7X8BoSCECUIVs T4z5UFT9oPUCIsdTjzOocn8nT0dD7PVwRzsO2a4R5sNyYe6R4TdBqIWELcIiKhTpaMQsfuEPuzFnwCV1L g zZhhR7yNIo14oupUUD0V0oIHIRvtM0MITOkSiTTmO68ROtezWPfdJQq9pQ6gdcPsy YAU0wMs dVFBTyTzPml55k VOgY4dEuHUC5BkDGwCm8BTvls07JdY4cwm1zsLq1xGuQfVYmr62WF7VeVVIKFX3FuAIOyFqIshJxA8rTnEtzL1eSxrVcabZ0j24i1Zv2D6SDvsbs45pPHNollnZJmKUkLfrldZzlNEuy4JkJa2ahzizZW72f5m2xiwDKgM3 g7nrbYLgIKUtXOdoJeKgUl2cN7j4Xd30dajZpcIDBqsZ LwmRYQlvRXFafWBMD3yQfU4GEzbWQlxV6iBidK83UVdyyvMKaqPvdqovPVQzhIK Xfs yVwnSHDXpjUonwsOFeykee9TcixuxkbYp3Md EBk4LcBDn4zFR3JSmz3FGfP1llIGL ZYWHrzjugMbxPXU02OrqExStd X1ALxTJq2W6mO4kQig4ZQFKHIs66EVWf6HG3SKAxzPAmmf4DZmlZGawG agiO2PrNnWyifOau4em ozqdkAbxu6mCbMEjMri7dkzpjtYFwkxUGpgSjfDm481Eby3SKvwNybwvqfj5CXHWSjGpk8YtJV0T3jzNd731Wb3SWQrVyIy2Wz1UntzYJ33O W9cFnumIVZK1Sj0pQwWoxktNdyknjXiL5COyZiZDBJOcNtIXoklXdBDy' |
   ✔  And no side effects
  Scenario: [8] Return a single-quoted string with 10000 characters
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
       | 'Qu7cFy732T2KJBCJzyY2xP7fWr4bhg7mdQALjUcVNa2nW2vIfAYMDxd4 ZGSe8g52kVWAiYI5K9SnVH2lMc7Uvh4M9hrvBUs5CPrAIjq9OwgxbVtZcfSrQgRe7hbkx162n0SNvY3KvqBBT5gyhTe4cG2BwJjFx8y11zpf0zyLpnYeQtd6V5maSx9tBigoLnjWdu9pjZ3aycAY8ZpzzOoBniPWThl1ydWyA8E4blXlzkeXnR9GY2UCpHpdmsg5u0GkF4phyqPt61 QRUiJBFXIHDx0zljppa vNLVbIaz8AqM7CGXU5796XKbiCX6uM9WRJXtUooJBJv0uHowr1tey4GQEL4t7j0tE4MznU9X7gRx7BMQGREyCBl5yR6qstIuMKug95TsVxUK3uE1oE5VsS68GlnL6IBAeNhsNMTA4kEflKNI2XKYGf4aDBLABvRa5Qbm12JpccslBbaILFQgQkPBy5nPRfh9Brjpyif1fPPkFB1rJIn 2z4G4irjFafOMuB 4JFTJnvj3 65yEbX7bNtgEF4oB7b7On8DVUAfFQfSz6T1SAFnOatwsNTts6dcH5JewU3jkS4TihfDUvAvw sjo0qoNxowKCoOtOUybt31Xg2mpeV5y5lyxZCSBkqjADNwLglwVcFa08Go3gU qP xs Hrw7ZmQ6vcy6oS6UH R3cJBUKWslkZKEYhXct3duSSWsnn8QFzKm6B4U6dmYXttjjVED0tqPXQ2vwp9eN8jJPebjZfT453810lZM9cQlfOhLdgsSaNaszT8t9pbPC5SrPPPIaXKF2IwRY3uMqAtTJD03bW o8dA3ZqT9igCrKRRfVo5j82HfUzjm2kBh4VT3UXfLGyTnnWqBqQ5WUbmdQQNfiMqGpBIcktEhov1XlJ6DyAzrn 1s yDyQS4Pjqg6y7NHl09nnJ3aMOxdDE7BHv4HVethC3Db32LHv6ZW9zotdOZ8tSH2AGKwhND6cfum67hSXu5OsAGeLZxrrMIn9ml9VWZj8Qxar 3lw3OM2jeUB62REWg7lxTJp3zVuaCQgejCGh40wOPR4vYtyzLdFxsxZ2qwn3XvnO2Xw25KckV8dstFfv4w9NFe03VTBWhoYkuSl0j3eCB1absxURBvss7ReatCgqonoVtkwD5RgknklJg12R56ikPOa9akQwEY ri5X8xDrKyqo2FXrj Np8AmXc4nx0yxydL4yF6WVk J9HmgHjGP0M3dMFOl0n15BUPyTAQNQhAHhDcGjt3jvTqKDW A4GG6gK2xn7hfdgAuoDj4h1lMZsSyYIGTnV6Zig8Nlmtwtss9kjCx 234UQbVuBD96JXbrjmY5jHd7c10KRvUFFzlGcdTscUUi38q6f0czcpoeT8MFBgEbrAw2b50fzz5tLhBGJGeKE0ndK64LOWP0olrS0voljEXYRiLMEArn1bkNUcaOgtQHzoV1Pqp6CR4suZxza66QcNOPH CoSuReOfjYOs1f0hWQ2RU2BUg1vJ5OyRPxAZ81195eJg82WgMFxIo 3EwNLUH6j3D41mu9G2L4ckbETdQRy8PEeM1KSIIjEBLD7xJdXFneolAbsv81mKzrWYRXw0pA8hTI4aIFFQSE8aaUkPUmCE0hzUENcHeNNHMK2UqsClOAdxRiz58hrzdUROac 7UM97kncRVWBSuW4GtISDrgBoEAJQqR2IFIh93W9wKCrESYtjf5uGLzEsGn3l0b2B0jXBoTkbd05jweOTk9LUOgpeNGBNWlpinKda9ny3OfjjCIZx3NnVqsxYiFeV0r4EgE4Vd5QypPNSoQN7rNx2aGufdT52tf1tGeK2d9uVgjDKIjJjZsDJhmnaOUbT5KPYb7fDJ4FJUcl22SMtXAkmQZTbXxGAkyve2SD6pyNB6ShBJ9LkeJPKDWQybSdRD tlQnHVqboE9iYdYOQSblltZwiQHMZcy4eiUHqW7uJ3Mve7bwRZLXYgJEoHeR7E8MXc0SpbVLpbEKEItiqFoi0XEhPGrRvE1PUhphlwiTJBXoLdGO02G97kpy2E8AZtFwboyuW0TXMyEg3bgAP TvGBrbtHyuYfbX6TC1meqTQOGTEMUBjz2VzRB ouL nUpSH7DojvQdxGi8F13xP12K 3IDVZX3UkPAsDgdChHvG5mFiSAaOWBZzUGbGTBkW52NtUQCMkzwYoCNwooNh5Ewk9rNafQQCsrmwaZQGrV pl4u9dBgedBtOeVF7SbxDdOewY uOb1TxLPn9CLwY7KY7igUGZ1prFMUqQ6IsmDLebpOIlG uKI7Xkar6hoRj1Xm8yWPf9o5qkGk agGuD4HrZOA2CtNVsWKiWnV09NLSBd5LdVkhjDbCFGRevIHO1aPCHTPpkml0EStzJdDHVtmGt6EYkbTXUZz7UZs8gKxNs950gEG 4Vtj98io9N0xNbO8FjLL lIqo4LunkmUs0otjT3gmshVAVTwQ0SjCRhqBs10NqVHAT9jCv J3s4mRSoirWeWw7UtzqRc bYtZrpvzmKvP 9lVvuOlEvWhcufv2VUQniDZFYE2EDtNCWrAqiodSAeX5eHEbfbQ5CwJjDjpBHJwoa7lPcZpt43nsXDLvZoIJZPzRPWOzDbt5u3loDI8aYrF2HOmpZ1Lrei XVV3DGYok8M5cWFgfaDILw8sa3kmDDJ2erUPblmMJZZB9eEOLnvEl5O9ALYbBBpnVTnLJvedw9uPVr1HXDmNWgAVpUFYXxKeQVReEFkHT29vENZGi3g7Bv2VUgEx5BxTlHGa13Kmge9QliYARWNfhBPjWQoP2ZRoKCDalsOCeohq2pNOKvkgZOy3AwfpFykBoUjtsvI7NAg6zVhCtCSo6PHcryDgAYYRF737e82qLpjkbCpMozebQRoGrZ7deTFTy TZCiOP2nGOKWiMnGq1daw3uAOx3ntthuZR1viQ8qmyXiIaBwJF5REqFJbZdPvRTpXns8vsG9PsXu DkPiWh3LieaiMGM3zyBsdFheatoBnj0ccBSsiKSDH SmVyBPw8K5vAeVA5WQy8LXX27mzhA7rlrXdWH8kMmtK15lR2AHE7XmSrzGaUbqWGRzmfrTDM vJPKZ8y73x8jhCvVK34nqFZbvlIRdYaUfWjQIGhdJ60V0JMJsh3bvYMDOlDnviPgT5MoAP6LszNwTp4O4yzdxgmq7CY48bQigcLRYEmg8ZWBU6ekc0Gk8Uuj3qC2Oy4DviJoC5Sy68xnl762KjXseDWuO0US6k5NCcztEWuB41AhFLjT Xlfv7dJNvDvyrTwYbnapgnqRTq2fD0NlkKq 0Wmjgv8HRMAUOU4Sfh2PNem 4BK4fBQKbzZWjK8Mjh4quPQr23P4K3qfVfyqGU9Y7HWPRiaz 86zjtl0Gu6DGo92GqPEGNBs RVMTebDPNWQWZju4bqF01z9jnsyzLbG1PD5bqdZccxHK9E bD9AM0KjsT3bSvhG4wCqIUOH9VBFKARnrscsgtF7sbmiBwtt3RfX9cddLMWn8lxh6swaE1pFyN8sg4qRhjVBHv0viacoxg7glAHAowSaqJXKRUWO0wBLz7esMhv9H44d6ztNLrgfays65REWjKWuMe4RsSP7VLGrQRvG6QKZ2GyI5K3WdQRRsPl2QrSxzCEHR1feQLSkngRpWAi4Gwt0ZUHzTGLMZeDQpG9fYWjSRfuPBWm4rHYyI0ny6WmqZa3yi3zeaHXKsNMMxV5RhI3wcY3UdgRBNTG1 yogATPH JYM5tSqE3M6tPgUumwH3qba 7a9XZcAJF7MYjb214yDndl8CYcQiJ9xUnyta9DToaXdLDFMOxIWdv4Oc Ae 092ASura8P5qig9RUZAwUpWiJTnCz6fSEkb1XHzAgW4HwrczuFFGsRNAUY5cReitkmwpFhf4Jz8KHHbUj8fbDROSfdsmjInlHnwLsB1sjfvZG6vk3LffL78GSIZ5fPfDnFm3rc2A0AWP0Abu539HMhSFd967byWCgpKqWCyMBjW1b6ool1XPus5gM0hx10WdSbMsEpYRR2SwicTxN18oIR4pJaQkE6or9TX6rz9vV6ZEyb4 ud wHyp1I227JdmFLT79kilRqj9K9xWnDR7SlCYSrIVavAnAa1vp4OF4fIQv5ER0Yj61PgmVQQWorwnGK4B9ArBshfyu CTzvR2isHgEpXVRg q2c4c4u7S19M 2PlDrcryc1M0HR1oBmdAsy mIV0E8BR 5E4xi5ZmrKMCXnpH7jURkiDLcu6bsOBufpLbEhKCaFJoC5r3nKY59nohuSWOigeOkEIcdCJt3VaQdwL1doyWzdpG0lUsCP9ZzzIB5oOp5RGgkoGiAh 5WSB5gHlpeK7lDPm2JEulXLeh97fRmSxe4nOVgyGscjoFfi9PgFqDuntZZwsNLiiMfsX8W 97fDeOT0TWvHw7JuioLjxDtOOOBrnZlKkUZQ7CRy7ch38tA1DzJOcCb178efuhtH91QrhoHJn6csVBRrg0DL98BGshITV Rojhsgq7j4NSLircpRgENiVRh49HigUtgwH5AK7xIAjMpD1ky gLFMqpfp4l9vlNrBhTpPDCI1R9UQMeCpiSXnJ9UjtL4uoXfmraI9xY4yVxVZFBXyhhk BaCRXp92qhUege4cIsMfK47FVJLIXzqn3Nu1TPmVyxQmmqXw7NLvVVu12x3DRrsi8ouiedz1KwDXmDhR4cLlnnHSei62MXC0elxELoUAooeyWnLPj6irfATHZ2BvdHUHNXLMq0xqqwzWDsQPklXiI5UPrCi6LfKDvwa38SAyF460vkacS92lPRdrh9S7xjhUOVN7mvjRYdnCU5I5sNiBsQqiuo8aA3GjQkXO0zBnddviQinlSjDEqB97aqZlviAgLTYtM8nbN1tWUH8gayIEPcpC4GyC37WCRiRg0hgyeXbs9sA1nHm5pIZ6sWY33A849nLfYF28C1TB27YPGTlrbCGIZEB4j62BvYUUAxmVo8VXS3hqegl2NPEKX8viEqv qwJZn1YBNjXRlJ1CHd6kqi48 udquQQT4XJTCMpfzbS9HOpXq4SRZmJDrqgXSsY4HPGc xk8p2ZRBodSSpKH3z6YOJ6tdOJ8BRqrymXoIsE1YK63BLSSyD437qwJedJzpHUMiLRZWJ 5FTcYrdWUIh4d I98rGjwjmlAdzEKMtXl0aimE 3hQ2T14pGWF2BlIKQPiX Q2FlSssswVhXtfdUdaBSlBXSk1e2JXVh4a2X5F ENUoTSbAgRHm 0jeYe9Mgw7BAOv1IXWzqfEpBgca0DnbIaDhYGojuvYb3ZKygKzsEXWF9ybgSNdMXARHYfNru2MoI9EKQHEcAHwwBWWKevcr92SnF83UyNyoyATmfb76bqggDHg0e4OD7FYyQ16VhLFowFGew7OhN16urh5 SU9JxECvjmbpe3mY83MOtZR65FRq3FaxYSsEDgI41Ce3wsNgkUXaxmiUw8M6FUFwihz8ZEihfxMb41EAnafjOUo66tfs1bzzWFvGuuEXfLeHOs07YF7YSmwhs6smrP3SkWXJCQfEjr9kn8sGB2VBpmO7aTiIdGHBa2u hyjkJrTu64n54dknHBPMl2Yc nyEoHucwalDRjPBhPNTAenytix29MsVEFvnaEqgxkB1DbdbifGvkWAt9t86BWvbgE2hIPAGA6zcm43Wzg8ENZCLqVoGSAFe ZjpptB4c84l a1XxUUxo7fmmDdkFNaTZP6UFmkzFnhDt3NB Dzom5Px h5CEHIvdgRSbdBr9tlLkm9gBTbS3fTYjPTPBnnGyUZnOhLMS8CExBvaAdxh6lmprWxyfaLOfi4uqmDQ5VGmjexWZin2Q7QQBSDZaLoSImoZ0TytdMvwpdIHQysLtvdLUJ9Jmklz4C cwZM538cCfD97iMjkZ sGB95sShsGhgNCUwR35cmjMJfVuFtppu4iU3AZkXs0OyKFUxBMhLEHQYBM0U9H rV0rHJDW0LirrncRqtLBOvcj bC4jKiSN3slzd v2XbmKBd4tWKKLcgMZmtF99WcteKyYMCWkF62nBVTyZZsyxUWETHOB9O2B7dukuQuGFz28pQhR Qsf7xKo8cwjc66YYWj61OFt4qFO9miVOojp8MR2qhCXdl1tVVHoUPh8WnrEnPWT C9u5co4NUhSAUHwyPuMKbr jhx9u34vJNaAScYvGDKy3wmxB3ogzfWE7n yqN1RvxJl9 mc0vk3ObjaGUYidas4nK2fQaVeNvwebbr dHeLJF0f qHWUoJmBKg6d7owotrQ7beZcYO7J7vZRZv0P26JuM3he8Q hl2Lak9ViLes59a4zfOn rzS9swYagFbPhwll44Q7lfRQzbjs7OO6viaC3aCYPv5BAPB8F9k W6sKpfuY52rpez5W4LoBBmjYMz8j 9Sc5WPXj32Zic fCaM65d eFACBAwnQeJKohksmmx9GPBKEZScTHe0gVqOfKklUv7OITLOVFIXD311e8KoWg2L7RZgiWz1JHNPI1BL9jkY3aQW52b6OGDX LR HQf7WoT3lQF85ICLNVKbjzWUDEL2AOIWK0jxvTnFiDBH7y2b4MpfmAfWBXtUsJJfgUGG2VW3pTFOqQS6rWir6jfvQs43ohSyt68RiZ1CfbR0Y9xY04fWPVsLKRlo9KM4JllXAwwKuSbvRpT4amOtbdkdKEKDPvmA6FQ61cSWayEADwjN8lbpUELdl150T9MjcDDdWZxv7nZ XAj493l8tUZlVGNXZ7OxOyoTf3PyIDCdtN9ut7TDBzpIFlDQhSBAHDY5cs5ct9nLzA6s1DGqdBj4NJPeRiKsPYGHnyqK5CE8S9IAJ 0XIfiJR so8fY9iySAKKECppnRk4hcdoVQhevjFBqAbSG02X1zkaKRXpvGxdWryFYL6TA9fVvRNpwi3JVSnhLslULMTcsnZeIkwN7QHWLDWh29DPXX31g7lLYdYnkiA53ZCCN0EKuwEpToy84vh3Gu8sO6Kv k6tHynKAVz0SentHsh 0LV387w8PQHYdYn7PzsQJ1sNmqIOyTn4Te7z1ElCSgqU0I0ImflD ilxsSUrsqaqhofXMyDkb5ZAaYGtFrhn Ea6 qw5ZCkbws8N8aY4gW90e90k9Rhhg0vE5nD74Rg5awiOA7vtmjn9LOKdLF67j1nVrpIZU4ADStXLwHWX0yCRFdw sfEKYuIrnFOc1sSjOKx fvHOSVGlYqaBv1yKqRBheU hsYupfxA3zzrlsYD71qZ4TmlqayGtK8p5SELT1mD0YG0v9VYPQrSqkrk V4kcPKckonY7zPZKkYbf6b5e22XVE0AWokBiYQwNuyIqEifpkhlc9PrUp13cwWncTlnMWyRDQrlW2i6oRJbMZJoE2Bcy72YMzbqvbcrmXnemI9tUDiHRZi0V1gbtxxvEjw 0 Z5UjDGk0jua35FOBRL4DdYRIawvkbzo7Lr 4PymJ0DrUu3k5IvBhQthdDJG7Dpf8Q4AiyUsZKkied3d7CFLKcpAmZ7up8J0pOcGEN3q0HsIUJ m1oW3acBCBXiYJ2 n JKAteFJPTgCqQzDhNOootC6BJXq4Ju4VUSdfD8poERjuadKYrInUCTKqRgU6H7N8B2lILyF GKnUT4mrxGxDduPrMIKE1wIdCOwAlD7H5V BYKZDF3GGwxsRU9Ktctq3tgatYQyB40VkWSftduesDqH118 2MhhZqYFwq8stqRqhFpYsjHwqY1owy yPnApsBOt7F7P9Y2NPCBziPywkY7nZiRhf2UtSLpWGPWlegIlkMCYtOB fNnPpxotXpOyUiNWcF TpwXxXrUG2PTnHouO2vtQOSS5OkbpDYPMgCNZI Pvc6WAV8H61FnNOaGJHYY8zmKGMNaqZg4XRpbDZKCd34aFJDmu6rXwzOf4LqagfuR6S3shK82phsJvJXpho6pkugIfCiai0Xw9qkUW2NT4DMiomcJmWEwUCnTEsZCUSN0Lxlz6Cm49 Jc8OBtlCYqGwOtQkK2Uqz0CYGxX9zUcu BYH2I00luXU6seC2vcn2ouX3oBmOkfg5GW4whSQJd0ahBvsRAvHMj2YAixGkZM9XE FgJqJYl98YoIUQtH7aOXkZfcgWsojqGo0v8DdZNjYuXJzUEgDzIbD xWwxjf2S1LeLieYDcqgnu6I6WpMlwaCAtReo tY7mLd5r2oxLABi7epYW6oZZrYxwhjZZNw1FgOo1OEWfwKn ApeXjiXDrQZb5rhwEjKGOE5uzI6Qohv3LIQgbBUL8rFU3g9FmkmmfdVtMGPpolkueiFzm4maKb8X4LLGiZ PeQfMGFQBW7UzH9PJFsVHecq96W6MVn6xbIiRItnuce61JXf7YWslpM1ktrFVzEF2hyEJSoMAec1Z3z2rEm33CBtOF9snfBky2ePmnioOm1yE8FpkyK7DVXGQEER2Zpz4nBGUalgPCNTQcOf34D4IY2Ucbn5 qMJzF5ibH0ogr6QmeSyRMQ3gWRp92RVpxD5sWQwKoCIagfhxevuLhz5k59zJqW5p82zcGiC3hcf3mMuJJ0IVibzNgepksfKRz19wGpOnnCKJW10jI7eW8EpF1pWdhTdcxZ7IGhMCFwj7ZHCmqNZLArfBI2gZYcKqR6hBDZYyzFj6SZ6J2X74JtFtIdWVasiyZ8gKviEAajZXIO2dn7cwwk17BWuFsP5NZ8l v07haNR0dcYwa9V4Nt3t8o7ZJSlXwELzODYA3WPsq4pUaof2dz8bsB1Fv2Hbe0VarRC9uqkthty1MImPBG5tDNbXZlTU4dh9Ph WIPtudfX3BRmptNHhJ5vPn2NJN41UIj70c0tgwNALFOgzk8NynQ5cGdz7CD8sQufqZPtlaDBV4ndTAgRpIg79DSA8SxN8eDQP4YrT6wDxJMxA9Aaerojes3EiQFc PVjqyqJ0oUDQvNK9rJ1ANrgJrcF jyk8BZtH Dipxg6HXKlDdLB5Tb8NObOnOBesJYHMY2iPQWKHhJc7g1hxJy9aUfdo5J4d9AyNDo83kPbNgqhsJO5tu7ZBaZVsJsV19H26SkHY8Z1vZOlQac7uKnqBZpp5OFwyHMOqIfw2Nf B6pmiF2lE1AlkMdICL2Nqh N8I54R918QZNNXDNtHnZWeLaGRqmS9DZBIwGkMm2COY3naU1IoF6yQY1MccPmebAdTNAmey1ArqvZCek5EXCJOoasrRE3qBIUSZXlU87odvxNCKJ78pZeP7U8Ed7RrnN3SbiDyEiY c7eDjdF4AAzcEr2 UlGGznQxBDriVuWBRWugpdIufzu5rk9KUe13Sa 5fPTAoHNXyjRIDObArGnjBHjPHPFM4nxyhk6mm2JCCYfNhKUmL5CBEf9jImdwRpu3KxQ1mv7bH9vKUWPcLMpVoX5P5gXvN1eOI0ZYyPoMDLd7UvcOrnjXL  2t4E0GG8TBRqLfbCLqyuBaePrnA0lIPHGQLMDoPe3IBidztyAhR KwoCWrwt2QbmvYs3KRaidfYuvMQ2 IlxUazVSZgJnc4PIpg cZkIWaTuQakpDyvJozz3yL2F4RIv14GovVvTq9QTpYkOvqHZxolngw0qpGbMeALhwFlWGpot5jgqeQjA VYA72jb2fxoWBl45AnqdW1czHYXG46kdRnUzrCenkF0mAkDuV0gRPY222BC7uWHAn6PTEWgDB3HyoBqPvanbc6s2ccdzSHJ4YJQWfAX td7UqFApODVkTbW6G7mjzuCeSpMoULyouH q1s0LjyECDXokV1Kri KhWGJUugEuxquue vh9AVw09QW fhya0F8ZmKVqD78G9EFbpMQjvOvgPlmCcvUmnxi3PXFDNkJG8WRPzocUVe3PTw0E3eEHghOKiEB4u0Xvt2Hb2esODlsJ5Uajn7B46Bq0w3W55MDUw0U5i8CP6QDrizWsQOYQOCF3vpLGOCVIyeleOWkVPz51u30XZCD7jKlRYvYOw2Rxocfq2YdbPZcvhPN7iRT ToHlNUY' |
   ✔  And no side effects
  Scenario: [9] Return a double-quoted empty string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | ''      |
   ✔  And no side effects
  Scenario: [10] Accept valid Unicode literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    |
       | 'ǿ'  |
   ✔  And no side effects
  Scenario: [11] Return a double-quoted string with one character
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | 'a'     |
   ✔  And no side effects
  Scenario: [12] Return a double-quoted string with uft-8 characters
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal             |
       | '🧐🍌❖⋙⚐'             |
   ✔  And no side effects
  Scenario: [13] Failing on incorrect unicode literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidUnicodeLiteral
Feature: Literals7 - List
  Scenario: [1] Return an empty list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | []      |
   ✔  And no side effects
  Scenario: [2] Return a list containing a boolean
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | [false] |
   ✔  And no side effects
  Scenario: [3] Return a list containing a null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | [null]  |
   ✔  And no side effects
  Scenario: [4] Return a list containing a integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | [1]     |
   ✔  And no side effects
  Scenario: [5] Return a list containing a hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal      |
       | [-372036854] |
   ✔  And no side effects
  Scenario: [6] Return a list containing a octal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal     |
       | [372036854] |
   ✔  And no side effects
  Scenario: [7] Return a list containing a float
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal     |
       | [-0.000001] |
   ✔  And no side effects
  Scenario: [8] Return a list containing a string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal             |
       | ['abc, as#?lßdj ']  |
   ✔  And no side effects
  Scenario: [9] Return a list containing an empty lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | [[]]    |
   ✔  And no side effects
  Scenario: [10] Return seven-deep nested empty lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal        |
       | [[[[[[[]]]]]]] |
   ✔  And no side effects
  Scenario: [11] Return 20-deep nested empty lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                  |
       | [[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]] |
   ✔  And no side effects
  Scenario: [12] Return 40-deep nested empty lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                                                          |
       | [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] |
   ✔  And no side effects
  Scenario: [13] Return a list containing an empty map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | [{}]    |
   ✔  And no side effects
  Scenario: [14] Return a list containing multiple integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                     |
       | [1, -2, 63, 2636, 71034856] |
   ✔  And no side effects
  Scenario: [16] Return a list containing multiple mixed values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                      |
       | [0.2, ', as#?lßdj ', null, 71034856, false]  |
   ✔  And no side effects
  Scenario: [17] Return a list containing real and fake nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                                        |
       | [null, [' a ', ' '], ' [ a ', ' [ ], ] ', ' [ ', [' '], ' ] '] |
   ✔  And no side effects
  Scenario: [18] Return a complex list containing multiple mixed and nested values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
       | [{id: '0001', type: 'donut', name: 'Cake', ppu: 0.55, batters: {batter: [{id: '1001', type: 'Regular'}, {id: '1002', type: 'Chocolate'}, {id: '1003', type: 'Blueberry'}, {id: '1004', type: 'Devils Food'}]}, topping: [{id: '5001', type: 'None'}, {id: '5002', type: 'Glazed'}, {id: '5005', type: 'Sugar'}, {id: '5007', type: 'Powdered Sugar'}, {id: '5006', type: 'Chocolate Sprinkles'}, {id: '5003', type: 'Chocolate'}, {id: '5004', type: 'Maple'}]}, {id: '0002', type: 'donut', name: 'Raised', ppu: 0.55, batters: {batter: [{id: '1001', type: 'Regular'}]}, topping: [{id: '5001', type: 'None'}, {id: '5002', type: 'Glazed'}, {id: '5005', type: 'Sugar'}, {id: '5003', type: 'Chocolate'}, {id: '5004', type: 'Maple'}]}, {id: '0003', type: 'donut', name: 'Old Fashioned', ppu: 0.55, batters: {batter: [{id: '1001', type: 'Regular'}, {id: '1002', type: 'Chocolate'}]}, topping: [{id: '5001', type: 'None'}, {id: '5002', type: 'Glazed'}, {id: '5003', type: 'Chocolate'}, {id: '5004', type: 'Maple'}]}] |
   ✔  And no side effects
  Scenario: [19] Fail on a list containing only a comma
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [20] Fail on a nested list with non-matching brackets
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [21] Fail on a nested list with missing commas
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
Feature: Literals8 - Maps
  Scenario: [1] Return an empty map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | {}      |
   ✔  And no side effects
  Scenario: [2] Return a map containing one value with alphabetic lower case key
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal  |
       | {abc: 1} |
   ✔  And no side effects
  Scenario: [3] Return a map containing one value with alphabetic upper case key
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal  |
       | {ABC: 1} |
   ✔  And no side effects
  Scenario: [4] Return a map containing one value with alphabetic mixed case key
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal     |
       | {aBCdeF: 1} |
   ✔  And no side effects
  Scenario: [5] Return a map containing one value with alphanumeric mixed case key
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal        |
       | {a1B2c3e67: 1} |
   ✔  And no side effects
  Scenario: [6] Return a map containing a boolean
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal    |
       | {k: false} |
   ✔  And no side effects
  Scenario: [7] Return a map containing a null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal   |
       | {k: null} |
   ✔  And no side effects
  Scenario: [8] Return a map containing a integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | {k: 1}  |
   ✔  And no side effects
  Scenario: [9] Return a map containing a hexadecimal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal         |
       | {F: -372036854} |
   ✔  And no side effects
  Scenario: [10] Return a map containing a octal integer
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal        |
       | {k: 372036854} |
   ✔  And no side effects
  Scenario: [11] Return a map containing a float
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal        |
       | {k: -0.000001} |
   ✔  And no side effects
  Scenario: [12] Return a map containing a string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                  |
       | {k: 'ab: c, as#?lßdj '}  |
   ✔  And no side effects
  Scenario: [13] Return a map containing an empty map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal |
       | {a: {}} |
   ✔  And no side effects
  Scenario: [14] Return seven-deep nested maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                |
       | {a1: {a2: {a3: {a4: {a5: {a6: {}}}}}}} |
   ✔  And no side effects
  Scenario: [15] Return 20-deep nested maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                                                                                                        |
       | {a1: {a2: {a3: {a4: {a5: {a6: {a7: {a8: {a9: {a10: {a11: {a12: {a13: {a14: {a15: {a16: {a17: {a18: {a19: {}}}}}}}}}}}}}}}}}}}} |
   ✔  And no side effects
  Scenario: [16] Return 40-deep nested maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                                                                                                                                                                                                                                                    |
       | {a1: {a2: {a3: {a4: {a5: {a6: {a7: {a8: {a9: {a10: {a11: {a12: {a13: {a14: {a15: {a16: {a17: {a18: {a19: {a20: {a21: {a22: {a23: {a24: {a25: {a26: {a27: {a28: {a29: {a30: {a31: {a32: {a33: {a34: {a35: {a36: {a37: {a38: {a39: {}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} |
   ✔  And no side effects
  Scenario: [17] Return a map containing real and fake nested maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                               |
       | {a: ' { b : ', c: {d: ' '}, d: ' } '} |
   ✔  And no side effects
  Scenario: [18] Return a complex map containing multiple mixed and nested values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | literal                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
       | {data: [{id: '0001', type: 'donut', name: 'Cake', ppu: 0.55, batters: {batter: [{id: '1001', type: 'Regular'}, {id: '1002', type: 'Chocolate'}, {id: '1003', type: 'Blueberry'}, {id: '1004', type: 'Devils Food'}]}, topping: [{id: '5001', type: 'None'}, {id: '5002', type: 'Glazed'}, {id: '5005', type: 'Sugar'}, {id: '5007', type: 'Powdered Sugar'}, {id: '5006', type: 'Chocolate Sprinkles'}, {id: '5003', type: 'Chocolate'}, {id: '5004', type: 'Maple'}]}, {id: '0002', type: 'donut', name: 'Raised', ppu: 0.55, batters: {batter: [{id: '1001', type: 'Regular'}]}, topping: [{id: '5001', type: 'None'}, {id: '5002', type: 'Glazed'}, {id: '5005', type: 'Sugar'}, {id: '5003', type: 'Chocolate'}, {id: '5004', type: 'Maple'}]}, {id: '0003', type: 'donut', name: 'Old Fashioned', ppu: 0.55, batters: {batter: [{id: '1001', type: 'Regular'}, {id: '1002', type: 'Chocolate'}]}, topping: [{id: '5001', type: 'None'}, {id: '5002', type: 'Glazed'}, {id: '5003', type: 'Chocolate'}, {id: '5004', type: 'Maple'}]}]} |
   ✔  And no side effects
  Scenario: [19] Fail on a map containing key starting with a number
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [20] Fail on a map containing key with symbol
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [21] Fail on a map containing key with dot
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [22] Fail on a map containing unquoted string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario: [23] Fail on a map containing only a comma
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [24] Fail on a map containing a value without key
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [25] Fail on a map containing a list without key
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [26] Fail on a map containing a map without key
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [27] Fail on a nested map with non-matching braces
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
Feature: Map1 - Static value access
  Scenario: [1] Statically access a field of a non-null map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m.missing | m.notMissing | m.existing |
       | null      | null         | 42         |
   ✔  And no side effects
  Scenario: [2] Statically access a field of a null map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | m.missing |
       | null      |
   ✔  And no side effects
  Scenario: [3] Statically access a field of a map resulting from an expression
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | (list[1]).missing | (list[1]).notMissing | (list[1]).existing |
       | null              | null                 | 42                 |
   ✔  And no side effects
  Scenario Outline: [4] Statically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'Mats' |
   ✔  And no side effects
  Scenario Outline: [4] Statically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'Mats' |
   ✔  And no side effects
  Scenario Outline: [4] Statically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | 'Pontus' |
   ✔  And no side effects
  Scenario Outline: [4] Statically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [5] Statically access a field with a delimited identifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'Mats' |
   ✔  And no side effects
  Scenario Outline: [5] Statically access a field with a delimited identifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | 'Pontus' |
   ✔  And no side effects
  Scenario Outline: [5] Statically access a field with a delimited identifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [5] Statically access a field with a delimited identifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [5] Statically access a field with a delimited identifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'Mats' |
   ✔  And no side effects
  Scenario Outline: [5] Statically access a field with a delimited identifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | 'Pontus' |
   ✔  And no side effects
  Scenario Outline: [6] Fail when performing property access on a non-map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [6] Fail when performing property access on a non-map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [6] Fail when performing property access on a non-map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [6] Fail when performing property access on a non-map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [6] Fail when performing property access on a non-map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [6] Fail when performing property access on a non-map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a TypeError should be raised at compile time: InvalidArgumentType
Feature: Map2 - Dynamic Value Access
  Scenario: [1] Dynamically access a field based on parameters when there is no type information
   ✔  Given any graph
   ✔  And parameters are:
       | expr | {name: 'Apa'} |
       | idx  | 'name'        |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | 'Apa' |
   ✔  And no side effects
  Scenario: [2] Dynamically access a field based on parameters when there is rhs type information
   ✔  Given any graph
   ✔  And parameters are:
       | expr | {name: 'Apa'} |
       | idx  | 'name'        |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | 'Apa' |
   ✔  And no side effects
  Scenario: [3] Dynamically access a field on null results in null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | null  |
   ✔  And no side effects
  Scenario: [4] Dynamically access a field with null results in null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | null  |
   ✔  And no side effects
  Scenario Outline: [5] Dynamically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'Mats' |
   ✔  And no side effects
  Scenario Outline: [5] Dynamically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'Mats' |
   ✔  And no side effects
  Scenario Outline: [5] Dynamically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | 'Pontus' |
   ✔  And no side effects
  Scenario Outline: [5] Dynamically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [5] Dynamically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [5] Dynamically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 'Mats' |
   ✔  And no side effects
  Scenario Outline: [5] Dynamically access a field is case-sensitive
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | 'Pontus' |
   ✔  And no side effects
  Scenario: [6] Fail at runtime when attempting to index with an Int into a Map
   ✔  Given any graph
   ✔  And parameters are:
       | expr | {name: 'Apa'} |
       | idx  | 0             |
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: MapElementAccessByNonString
      Step skipped: tests/tck/features/expressions/map/Map2.feature:120:5
  Scenario: [7] Fail at runtime when trying to index into a map with a non-string
   ✔  Given any graph
   ✔  And parameters are:
       | expr | {name: 'Apa'} |
       | idx  | 12.3          |
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: MapElementAccessByNonString
      Step skipped: tests/tck/features/expressions/map/Map2.feature:132:5
  Scenario: [8] Fail at runtime when trying to index something which is not a map
   ✔  Given any graph
   ✔  And parameters are:
       | expr | 100 |
       | idx  | 0   |
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentType
      Step skipped: tests/tck/features/expressions/map/Map2.feature:144:5
Feature: Map3 - Keys function
  Scenario: [1] Using `keys()` on a literal map
   ✔  Given any graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | k                          |
       | ['name', 'age', 'address'] |
      Step skipped: tests/tck/features/expressions/map/Map3.feature:39:5
  Scenario: [2] Using `keys()` on a parameter map
   ✔  Given any graph
   ✔  And parameters are:
       | param | {name: 'Alice', age: 38, address: {city: 'London', residential: true}} |
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | k                          |
       | ['address', 'name', 'age'] |
      Step skipped: tests/tck/features/expressions/map/Map3.feature:52:5
  Scenario: [3] Using `keys()` on null map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | keys(m) | keys(null) |
       | null    | null       |
   ✔  And no side effects
  Scenario Outline: [4] Using `keys()` on map with null values
   ✔  Given any graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | keys |
       | []   |
      Step skipped: tests/tck/features/expressions/map/Map3.feature:75:5
  Scenario Outline: [4] Using `keys()` on map with null values
   ✔  Given any graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | keys  |
       | ['k'] |
      Step skipped: tests/tck/features/expressions/map/Map3.feature:75:5
  Scenario Outline: [4] Using `keys()` on map with null values
   ✔  Given any graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | keys  |
       | ['k'] |
      Step skipped: tests/tck/features/expressions/map/Map3.feature:75:5
  Scenario Outline: [4] Using `keys()` on map with null values
   ✔  Given any graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | keys       |
       | ['k', 'l'] |
      Step skipped: tests/tck/features/expressions/map/Map3.feature:75:5
  Scenario Outline: [4] Using `keys()` on map with null values
   ✔  Given any graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | keys       |
       | ['k', 'l'] |
      Step skipped: tests/tck/features/expressions/map/Map3.feature:75:5
  Scenario Outline: [4] Using `keys()` on map with null values
   ✔  Given any graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | keys       |
       | ['k', 'l'] |
      Step skipped: tests/tck/features/expressions/map/Map3.feature:75:5
  Scenario Outline: [4] Using `keys()` on map with null values
   ✔  Given any graph
   ✔  When executing query:
   ?  Then the result should be (ignoring element order for lists):
       | keys            |
       | ['k', 'l', 'm'] |
      Step skipped: tests/tck/features/expressions/map/Map3.feature:75:5
  Scenario: [5] Using `keys()` and `IN` to check field existence
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
Feature: Mathematical11 - Signed numbers functions
  Scenario: [1] Absolute function
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | abs(-1) |
       | 1       |
   ✔  And no side effects
Feature: Mathematical13 - Square root
  Scenario: [1] `sqrt()` returning float values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sqrt(12.96) |
       | 3.6         |
   ✔  And no side effects
Feature: Mathematical2 - Addition
  Scenario: [1] Allow addition
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a.version + 5 |
       | 104           |
   ✔  And no side effects
Feature: Mathematical3 - Subtraction
  Scenario: [1] Fail for invalid Unicode hyphen in subtraction
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidUnicodeCharacter
Feature: Mathematical8 - Arithmetic precedence
  Scenario: [1] Arithmetic precedence test
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | 12 / 4 * 3 - 2 * 4 |
       | 1                  |
   ✔  And no side effects
  Scenario: [2] Arithmetic precedence with parenthesis test
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | 12 / 4 * (3 - 2 * 4) |
       | -15                  |
   ✔  And no side effects
Feature: Null1 - IS NULL validation
  Scenario: [1] Property null check on non-null node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.missing IS NULL | n.exists IS NULL |
       | true              | false            |
   ✔  And no side effects
  Scenario: [2] Property null check on optional non-null node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.missing IS NULL | n.exists IS NULL |
       | true              | false            |
   ✔  And no side effects
  Scenario: [3] Property null check on null node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.missing IS NULL |
       | true              |
   ✔  And no side effects
  Scenario: [4] A literal null IS null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | true  |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario: [6] IS NULL is case insensitive
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n               | b     |
       | (:X {prop: 42}) | false |
       | (:X)            | true  |
   ✔  And no side effects
Feature: Null2 - IS NOT NULL validation
  Scenario: [1] Property not null check on non-null node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.missing IS NOT NULL | n.exists IS NOT NULL |
       | false                 | true                 |
   ✔  And no side effects
  Scenario: [2] Property not null check on optional non-null node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.missing IS NOT NULL | n.exists IS NOT NULL |
       | false                 | true                 |
   ✔  And no side effects
  Scenario: [3] Property not null check on null node
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n.missing IS NOT NULL |
       | false                 |
   ✔  And no side effects
  Scenario: [4] A literal null is not IS NOT null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | false |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] IS NOT NULL on a map
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [6] IS NOT NULL is case insensitive
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n               | b     |
       | (:X {prop: 42}) | true  |
       | (:X)            | false |
   ✔  And no side effects
Feature: Null3 - Null evaluation
  Scenario: [1] The inverse of a null is a null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | null  |
   ✔  And no side effects
  Scenario: [2] It is unknown - i.e. null - if a null is equal to a null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | null  |
   ✔  And no side effects
  Scenario: [3] It is unknown - i.e. null - if a null is not equal to a null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | value |
       | null  |
   ✔  And no side effects
  Scenario Outline: [4] Using null in IN
   ✔  Given any graph
   ✔  And parameters are:
       | elt  | null |
       | coll | null |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [4] Using null in IN
   ✔  Given any graph
   ✔  And parameters are:
       | elt  | null      |
       | coll | [1, 2, 3] |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [4] Using null in IN
   ✔  Given any graph
   ✔  And parameters are:
       | elt  | null            |
       | coll | [1, 2, 3, null] |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [4] Using null in IN
   ✔  Given any graph
   ✔  And parameters are:
       | elt  | null |
       | coll | []   |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Using null in IN
   ✔  Given any graph
   ✔  And parameters are:
       | elt  | 1               |
       | coll | [1, 2, 3, null] |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Using null in IN
   ✔  Given any graph
   ✔  And parameters are:
       | elt  | 1         |
       | coll | [null, 1] |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Using null in IN
   ✔  Given any graph
   ✔  And parameters are:
       | elt  | 5               |
       | coll | [1, 2, 3, null] |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
Feature: Path1 - Nodes of a path
  Scenario: [1] `nodes()` on null path
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | nodes(p) | nodes(null) |
       | null     | null        |
   ✔  And no side effects
Feature: Path2 - Relationships of a path
  Scenario: [1] Return relationships by fetching them from the path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | relationships(p)                   |
       | [[:REL {num: 1}], [:REL {num: 2}]] |
   ✔  And no side effects
  Scenario: [2] Return relationships by fetching them from the path - starting from the end
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | relationships(p)                   |
       | [[:REL {num: 1}], [:REL {num: 2}]] |
   ✔  And no side effects
  Scenario: [3] `relationships()` on null path
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | relationships(p) | relationships(null) |
       | null             | null                |
   ✔  And no side effects
Feature: Path3 - Length of a path
  Scenario: [1] Return a var length path of length zero
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | l |
       | (:A) | (:A) | 0 |
       | (:B) | (:B) | 0 |
       | (:A) | (:B) | 1 |
   ✔  And no side effects
  Scenario: [2] Failing when using `length()` on a node
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario: [3] Failing when using `length()` on a relationship
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Pattern1 - Pattern predicate
  Scenario: [1] Matching on any single outgoing directed connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:A) |
       | (:B) |
   ✔  And no side effects
  Scenario: [2] Matching on a single undirected connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:A) |
       | (:B) |
       | (:C) |
       | (:D) |
   ✔  And no side effects
  Scenario: [3] Matching on any single incoming directed connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:A) |
       | (:B) |
       | (:C) |
       | (:D) |
   ✔  And no side effects
  Scenario: [4] Matching on a specific type of single outgoing directed connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:A) |
   ✔  And no side effects
  Scenario: [5] Matching on a specific type of single undirected connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:A) |
       | (:B) |
       | (:D) |
   ✔  And no side effects
  Scenario: [6] Matching on a specific type of single incoming directed connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:B) |
       | (:D) |
   ✔  And no side effects
  Scenario: [7] Matching on a specific type of a variable length outgoing directed connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:A) |
   ✔  And no side effects
  Scenario: [8] Matching on a specific type of variable length undirected connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:A) |
       | (:B) |
       | (:D) |
   ✔  And no side effects
  Scenario: [9] Matching on a specific type of variable length incoming directed connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:B) |
       | (:D) |
   ✔  And no side effects
  Scenario: [10] Matching on a specific type of undirected connection with length 2
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:B) |
       | (:D) |
   ✔  And no side effects
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario Outline: [10] Fail on introducing unbounded variables in pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UndefinedVariable
  Scenario: [11] Fail on checking self pattern
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario: [12] Matching two nodes on a single directed connection between them
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    | m    |
       | (:A) | (:B) |
       | (:B) | (:A) |
       | (:A) | (:C) |
       | (:A) | (:D) |
   ✔  And no side effects
  Scenario: [13] Fail on matching two nodes on a single undirected connection between them
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    | m    |
       | (:A) | (:B) |
       | (:B) | (:A) |
       | (:A) | (:C) |
       | (:A) | (:D) |
       | (:C) | (:A) |
       | (:D) | (:A) |
   ✔  And no side effects
  Scenario: [14] Matching two nodes on a specific type of single outgoing directed connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    | m    |
       | (:A) | (:B) |
       | (:A) | (:D) |
   ✔  And no side effects
  Scenario: [15] Matching two nodes on a specific type of single undirected connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    | m    |
       | (:A) | (:B) |
       | (:B) | (:A) |
       | (:A) | (:D) |
       | (:D) | (:A) |
   ✔  And no side effects
  Scenario: [16] Matching two nodes on a specific type of a variable length outgoing directed connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    | m    |
       | (:A) | (:B) |
       | (:A) | (:D) |
   ✔  And no side effects
  Scenario: [17] Matching two nodes on a specific type of variable length undirected connection
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    | m    |
       | (:A) | (:B) |
       | (:A) | (:D) |
       | (:B) | (:A) |
       | (:B) | (:D) |
       | (:D) | (:A) |
       | (:D) | (:B) |
   ✔  And no side effects
  Scenario: [18] Matching two nodes on a specific type of undirected connection with length 2
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    | m    |
       | (:D) | (:B) |
       | (:B) | (:D) |
   ✔  And no side effects
  Scenario: [19] Using a negated existential pattern predicate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:C) |
       | (:D) |
   ✔  And no side effects
  Scenario: [20] Using two existential pattern predicates in a conjunction
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:A) |
   ✔  And no side effects
  Scenario: [21] Using two existential pattern predicates in a disjunction
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n    |
       | (:A) |
       | (:B) |
       | (:D) |
   ✔  And no side effects
  Scenario: [22] Fail on using pattern in RETURN projection
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [23] Fail on using pattern in WITH projection
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
  Scenario: [24] Fail on using pattern in right-hand side of SET
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: UnexpectedSyntax
Feature: Pattern2 - Pattern Comprehension
  Scenario: [1] Return a pattern comprehension
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                |
       | [<(:A)-[:T]->(:B)>] |
       | [<(:B)-[:T]->(:C)>] |
       | []                  |
   ✔  And no side effects
  Scenario: [2] Return a pattern comprehension with label predicate
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                |
       | [<(:A)-[:T]->(:B)>] |
   ✔  And no side effects
  Scenario: [3] Return a pattern comprehension with bound nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                |
       | [<(:A)-[:T]->(:B)>] |
   ✔  And no side effects
  Scenario: [4] Introduce a new node variable in pattern comprehension
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list    |
       | ['val'] |
       | [null]  |
       | []      |
   ✔  And no side effects
  Scenario: [5] Introduce a new relationship variable in pattern comprehension
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list    |
       | ['val'] |
       | [null]  |
       | []      |
   ✔  And no side effects
  Scenario: [6] Aggregate on a pattern comprehension
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c |
       | 3 |
   ✔  And no side effects
  Scenario: [7] Use a pattern comprehension inside a list comprehension
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | n           | list   |
       | (:X {n: 1}) | [1, 2] |
       | (:X {n: 2}) | [0, 1] |
   ✔  And no side effects
  Scenario: [8] Use a pattern comprehension in WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ps                  | c |
       | [<(:A)-[:T]->(:B)>] | 1 |
       | [<(:B)-[:T]->(:C)>] | 1 |
   ✔  And no side effects
  Scenario: [9] Use a variable-length pattern comprehension in WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | paths               | c |
       | [<(:A)-[:T]->(:B)>] | 1 |
   ✔  And no side effects
  Scenario: [10] Use a pattern comprehension in RETURN
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ps                  |
       | [<(:A)-[:HAS]->()>] |
       | []                  |
       | []                  |
   ✔  And no side effects
  Scenario: [11] Use a pattern comprehension and ORDER BY
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in order:
       | isNew                               |
       | [<({time: 10})-[:T]->({time: 20})>] |
       | [<({time: 20})<-[:T]-({time: 10})>] |
   ✔  And no side effects
Feature: Precedence1 - On boolean values
  Scenario: [1] Exclusive disjunction takes precedence over inclusive disjunction
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario: [2] Conjunction disjunction takes precedence over exclusive disjunction
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario: [3] Conjunction disjunction takes precedence over inclusive disjunction
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario: [4] Negation takes precedence over conjunction
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario: [5] Negation takes precedence over inclusive disjunction
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario: [6] Comparison operator takes precedence over boolean negation
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario: [7] Comparison operator takes precedence over binary boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario: [8] Null predicate takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario: [9] Null predicate takes precedence over negation
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario: [10] Null predicate takes precedence over boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario: [11] List predicate takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario: [12] List predicate takes precedence over negation
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario: [13] List predicate takes precedence over boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario: [14] Exclusive disjunction takes precedence over inclusive disjunction in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario: [15] Conjunction takes precedence over exclusive disjunction in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario: [16] Conjunction takes precedence over inclusive disjunction in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario: [17] Negation takes precedence over conjunction in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario: [18] Negation takes precedence over inclusive disjunction in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [19] Comparison operators takes precedence over boolean negation in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [19] Comparison operators takes precedence over boolean negation in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [19] Comparison operators takes precedence over boolean negation in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [19] Comparison operators takes precedence over boolean negation in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [20] Pairs of comparison operators and boolean negation that are associative in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [20] Pairs of comparison operators and boolean negation that are associative in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [21] Comparison operators take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [22] Pairs of comparison operators and binary boolean operators that are associative in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [22] Pairs of comparison operators and binary boolean operators that are associative in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [22] Pairs of comparison operators and binary boolean operators that are associative in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [22] Pairs of comparison operators and binary boolean operators that are associative in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [23] Null predicates take precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [24] Null predicates take precedence over boolean negation on every truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [24] Null predicates take precedence over boolean negation on every truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [25] Null predicates take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [25] Null predicates take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [25] Null predicates take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [25] Null predicates take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [25] Null predicates take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [25] Null predicates take precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [26] List predicate takes precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [26] List predicate takes precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [26] List predicate takes precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [26] List predicate takes precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [26] List predicate takes precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [26] List predicate takes precedence over comparison operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario: [27] List predicate takes precedence over negation in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [28] List predicate takes precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [28] List predicate takes precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [28] List predicate takes precedence over binary boolean operators in every combination of truth values
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
Feature: Precedence2 - On numeric values
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a  | b  | c  |
       | 14 | 14 | 40 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c  |
       | 9 | 9 | 10 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c |
       | 9 | 9 | 0 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c  |
       | 2 | 2 | -8 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c  |
       | 7 | 7 | -2 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c |
       | 7 | 7 | 0 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c |
       | 8 | 8 | 0 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c |
       | 3 | 3 | 0 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c |
       | 3 | 3 | 0 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a  | b  | c  |
       | -4 | -4 | -8 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c  |
       | 1 | 1 | -2 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c |
       | 1 | 1 | 0 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c |
       | 6 | 6 | 8 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c |
       | 1 | 1 | 2 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a | b | c |
       | 1 | 1 | 0 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a  | b  | c |
       | -6 | -6 | 0 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a  | b  | c |
       | -1 | -1 | 0 |
   ✔  And no side effects
  Scenario Outline: [1] Numeric multiplicative operations takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a  | b  | c |
       | -1 | -1 | 0 |
   ✔  And no side effects
  Scenario Outline: [2] Exponentiation takes precedence over numeric multiplicative operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c             |
       | 512.0 | 512.0 | 68719476736.0 |
   ✔  And no side effects
  Scenario Outline: [2] Exponentiation takes precedence over numeric multiplicative operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a   | b   | c    |
       | 8.0 | 8.0 | 64.0 |
   ✔  And no side effects
  Scenario Outline: [2] Exponentiation takes precedence over numeric multiplicative operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a   | b   | c    |
       | 0.0 | 0.0 | 64.0 |
   ✔  And no side effects
  Scenario Outline: [3] Exponentiation takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c            |
       | 72.0 | 72.0 | 1073741824.0 |
   ✔  And no side effects
  Scenario Outline: [3] Exponentiation takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | 56.0 | 56.0 | 64.0 |
   ✔  And no side effects
  Scenario: [4] Numeric unary negative takes precedence over exponentiation
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a   | b   | c    |
       | 9.0 | 9.0 | -9.0 |
   ✔  And no side effects
  Scenario Outline: [5] Numeric unary negative takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a  | b  | c  |
       | -1 | -1 | -5 |
   ✔  And no side effects
  Scenario Outline: [5] Numeric unary negative takes precedence over numeric additive operations
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a  | b  | c  |
       | -5 | -5 | -1 |
   ✔  And no side effects
Feature: Precedence3 - On list values
  Scenario: [1] List element access takes precedence over list appending
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                         | b                         | c |
       | [[1], [2, 3], [4, 5], 10] | [[1], [2, 3], [4, 5], 10] | 5 |
   ✔  And no side effects
  Scenario: [2] List element access takes precedence over list concatenation
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                           | b                           | c      |
       | [[1], [2, 3], [4, 5], 8, 9] | [[1], [2, 3], [4, 5], 8, 9] | [4, 5] |
   ✔  And no side effects
  Scenario: [3] List slicing takes precedence over list concatenation
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                                     | b                                     | c                |
       | [[1], [2, 3], [4, 5], [6, 7], [8, 9]] | [[1], [2, 3], [4, 5], [6, 7], [8, 9]] | [[2, 3], [4, 5]] |
   ✔  And no side effects
  Scenario: [4] List appending takes precedence over list element containment
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c             |
       | false | false | [1, false, 4] |
   ✔  And no side effects
  Scenario: [5] List concatenation takes precedence over list element containment
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c          | d             |
       | false | false | [false, 4] | [1, false, 4] |
   ✔  And no side effects
  Scenario Outline: [6] List element containment takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario Outline: [6] List element containment takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario Outline: [6] List element containment takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | null | null | false |
   ✔  And no side effects
  Scenario Outline: [6] List element containment takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | null | null | true |
   ✔  And no side effects
  Scenario Outline: [6] List element containment takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | null | null | false |
   ✔  And no side effects
  Scenario Outline: [6] List element containment takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | null | null | true |
   ✔  And no side effects
Feature: Precedence4 - On null value
  Scenario Outline: [1] Null predicate takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario Outline: [1] Null predicate takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario Outline: [1] Null predicate takes precedence over comparison operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario: [2] Null predicate takes precedence over boolean negation
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario Outline: [3] Null predicate takes precedence over binary boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | null | null | true |
   ✔  And no side effects
  Scenario Outline: [3] Null predicate takes precedence over binary boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario Outline: [3] Null predicate takes precedence over binary boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c    |
       | false | false | true |
   ✔  And no side effects
  Scenario Outline: [3] Null predicate takes precedence over binary boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | null | null | true |
   ✔  And no side effects
  Scenario Outline: [3] Null predicate takes precedence over binary boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario Outline: [3] Null predicate takes precedence over binary boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario Outline: [3] Null predicate takes precedence over binary boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c     |
       | true | true | false |
   ✔  And no side effects
  Scenario: [4] String predicate takes precedence over binary boolean operator
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    | d    |
       | true | null | true | null |
   ✔  And no side effects
Feature: Quantifier1 - None quantifier
  Scenario: [1] None quantifier is always true on empty list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | true | true | true |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier on list literal containing booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier on list literal containing booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier on list literal containing booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier on list literal containing booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier on list literal containing booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier on list literal containing booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier on list literal containing booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier on list literal containing booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier on list literal containing booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] None quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] None quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] None quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] None quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] None quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] None quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] None quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] None quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] None quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] None quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] None quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] None quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] None quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] None quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] None quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] None quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] None quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] None quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario: [8] None quantifier on list containing nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | nodes                                                  | result |
       | []                                                     | true   |
       | [(:A {name: 'a'})]                                     | false  |
       | [(:A {name: 'a'}), (:A {name: 'a'})]                   | false  |
       | [(:A {name: 'a'}), (:A {name: 'a'}), (:A {name: 'a'})] | false  |
       | [(:A {name: 'a'}), (:A {name: 'a'}), (:B {name: 'b'})] | false  |
       | [(:A {name: 'a'}), (:B {name: 'b'})]                   | false  |
       | [(:A {name: 'a'}), (:B {name: 'b'}), (:A {name: 'a'})] | false  |
       | [(:A {name: 'a'}), (:B {name: 'b'}), (:B {name: 'b'})] | false  |
       | [(:B {name: 'b'})]                                     | true   |
       | [(:B {name: 'b'}), (:A {name: 'a'})]                   | false  |
       | [(:B {name: 'b'}), (:A {name: 'a'}), (:A {name: 'a'})] | false  |
       | [(:B {name: 'b'}), (:A {name: 'a'}), (:B {name: 'b'})] | false  |
       | [(:B {name: 'b'}), (:B {name: 'b'})]                   | true   |
       | [(:B {name: 'b'}), (:B {name: 'b'}), (:A {name: 'a'})] | false  |
       | [(:B {name: 'b'}), (:B {name: 'b'}), (:B {name: 'b'})] | true   |
      Step failed:
      Defined: tests/tck/features/expressions/quantifier/Quantifier1.feature:220:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 2 has no matching expected row: Record { columns: ["nodes", "result"], values: {"nodes": List([Node(NodeValue { id: 5, labels: ["A"], properties: {"name": String("a")} })]), "result": Boolean(false)} }
  Scenario: [9] None quantifier on list containing relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | relationships                                             | result |
       | []                                                        | true   |
       | [[:RA {name: 'a'}]]                                       | false  |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}]]                    | false  |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}], [:RA {name: 'a'}]] | false  |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}], [:RB {name: 'b'}]] | false  |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}]]                    | false  |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}], [:RA {name: 'a'}]] | false  |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}], [:RB {name: 'b'}]] | false  |
       | [[:RB {name: 'b'}]]                                       | true   |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}]]                    | false  |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}], [:RA {name: 'a'}]] | false  |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}], [:RB {name: 'b'}]] | false  |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}]]                    | true   |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}], [:RA {name: 'a'}]] | false  |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}], [:RB {name: 'b'}]] | true   |
   ✔  And no side effects
  Scenario Outline: [10] None quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] None quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] None quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] None quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [10] None quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [10] None quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [10] None quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] None quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] None quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] None quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario: [13] None quantifier is true if the predicate is statically false and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario: [14] None quantifier is false if the predicate is statically true and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [15] Fail none quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [15] Fail none quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [15] Fail none quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Quantifier10 - Single quantifier invariants
  Scenario: [1] Single quantifier is always false if the predicate is statically false and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [2] Single quantifier is always false if the predicate is statically true and the list has more than one element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [3] Single quantifier is always true if the predicate is statically true and the list has exactly one non-null element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier is always equal whether the size of the list filtered with same the predicate is one
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier is always equal whether the size of the list filtered with same the predicate is one
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier is always equal whether the size of the list filtered with same the predicate is one
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier is always equal whether the size of the list filtered with same the predicate is one
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier is always equal whether the size of the list filtered with same the predicate is one
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
Feature: Quantifier11 - Any quantifier invariants
  Scenario: [1] Any quantifier is always false if the predicate is statically false and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [2] Any quantifier is always true if the predicate is statically true and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier is always true if the single or the all quantifier is true
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier is always true if the single or the all quantifier is true
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier is always true if the single or the all quantifier is true
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier is always true if the single or the all quantifier is true
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier is always true if the single or the all quantifier is true
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier is always equal the boolean negative of the none quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier is always equal the boolean negative of the none quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier is always equal the boolean negative of the none quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier is always equal the boolean negative of the none quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier is always equal the boolean negative of the none quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier is always equal the boolean negative of the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier is always equal the boolean negative of the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier is always equal the boolean negative of the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier is always equal the boolean negative of the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier is always equal the boolean negative of the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier is always equal whether the size of the list filtered with same the predicate is grater zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier is always equal whether the size of the list filtered with same the predicate is grater zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier is always equal whether the size of the list filtered with same the predicate is grater zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier is always equal whether the size of the list filtered with same the predicate is grater zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier is always equal whether the size of the list filtered with same the predicate is grater zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
Feature: Quantifier12 - All quantifier invariants
  Scenario: [1] All quantifier is always false if the predicate is statically false and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [2] All quantifier is always true if the predicate is statically true and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier is always equal the none quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier is always equal the none quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier is always equal the none quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier is always equal the none quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier is always equal the none quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier is always equal the boolean negative of the any quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier is always equal the boolean negative of the any quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier is always equal the boolean negative of the any quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier is always equal the boolean negative of the any quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier is always equal the boolean negative of the any quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier is always equal whether the size of the list filtered with same the predicate is equal the size of the unfiltered list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier is always equal whether the size of the list filtered with same the predicate is equal the size of the unfiltered list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier is always equal whether the size of the list filtered with same the predicate is equal the size of the unfiltered list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier is always equal whether the size of the list filtered with same the predicate is equal the size of the unfiltered list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier is always equal whether the size of the list filtered with same the predicate is equal the size of the unfiltered list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
Feature: Quantifier2 - Single quantifier
  Scenario: [1] Single quantifier is always false on empty list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     |
       | false | false | false |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Single quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] Single quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] Single quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Single quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] Single quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Single quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Single quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] Single quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Single quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] Single quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Single quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Single quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Single quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Single quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Single quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Single quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Single quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Single quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Single quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Single quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Single quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Single quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Single quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Single quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Single quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Single quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Single quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Single quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [8] Single quantifier on list containing nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | nodes                                                  | result |
       | []                                                     | false  |
       | [(:A {name: 'a'})]                                     | true   |
       | [(:A {name: 'a'}), (:A {name: 'a'})]                   | false  |
       | [(:A {name: 'a'}), (:A {name: 'a'}), (:A {name: 'a'})] | false  |
       | [(:A {name: 'a'}), (:A {name: 'a'}), (:B {name: 'b'})] | false  |
       | [(:A {name: 'a'}), (:B {name: 'b'})]                   | true   |
       | [(:A {name: 'a'}), (:B {name: 'b'}), (:A {name: 'a'})] | false  |
       | [(:A {name: 'a'}), (:B {name: 'b'}), (:B {name: 'b'})] | true   |
       | [(:B {name: 'b'})]                                     | false  |
       | [(:B {name: 'b'}), (:A {name: 'a'})]                   | true   |
       | [(:B {name: 'b'}), (:A {name: 'a'}), (:A {name: 'a'})] | false  |
       | [(:B {name: 'b'}), (:A {name: 'a'}), (:B {name: 'b'})] | true   |
       | [(:B {name: 'b'}), (:B {name: 'b'})]                   | false  |
       | [(:B {name: 'b'}), (:B {name: 'b'}), (:A {name: 'a'})] | true   |
       | [(:B {name: 'b'}), (:B {name: 'b'}), (:B {name: 'b'})] | false  |
      Step failed:
      Defined: tests/tck/features/expressions/quantifier/Quantifier2.feature:220:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 2 has no matching expected row: Record { columns: ["nodes", "result"], values: {"nodes": List([Node(NodeValue { id: 5, labels: ["A"], properties: {"name": String("a")} })]), "result": Boolean(true)} }
  Scenario: [9] Single quantifier on list containing relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | relationships                                             | result |
       | []                                                        | false  |
       | [[:RA {name: 'a'}]]                                       | true   |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}]]                    | false  |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}], [:RA {name: 'a'}]] | false  |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}], [:RB {name: 'b'}]] | false  |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}]]                    | true   |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}], [:RA {name: 'a'}]] | false  |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}], [:RB {name: 'b'}]] | true   |
       | [[:RB {name: 'b'}]]                                       | false  |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}]]                    | true   |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}], [:RA {name: 'a'}]] | false  |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}], [:RB {name: 'b'}]] | true   |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}]]                    | false  |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}], [:RA {name: 'a'}]] | true   |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}], [:RB {name: 'b'}]] | false  |
   ✔  And no side effects
  Scenario Outline: [10] Single quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] Single quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] Single quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] Single quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] Single quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] Single quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [10] Single quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] Single quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] Single quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Single quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [13] Single quantifier is false if the predicate is statically false and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [14] Single quantifier is false if the predicate is statically true and the list has more than one element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [15] Single quantifier is true if the predicate is statically true and the list has exactly one non-null element
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [16] Fail single quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [16] Fail single quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [16] Fail single quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Quantifier3 - Any quantifier
  Scenario: [1] Any quantifier is always false on empty list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a     | b     | c     |
       | false | false | false |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Any quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Any quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Any quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] Any quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Any quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Any quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Any quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Any quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] Any quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [8] Any quantifier on list containing nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | nodes                                                  | result |
       | []                                                     | false  |
       | [(:A {name: 'a'})]                                     | true   |
       | [(:A {name: 'a'}), (:A {name: 'a'})]                   | true   |
       | [(:A {name: 'a'}), (:A {name: 'a'}), (:A {name: 'a'})] | true   |
       | [(:A {name: 'a'}), (:A {name: 'a'}), (:B {name: 'b'})] | true   |
       | [(:A {name: 'a'}), (:B {name: 'b'})]                   | true   |
       | [(:A {name: 'a'}), (:B {name: 'b'}), (:A {name: 'a'})] | true   |
       | [(:A {name: 'a'}), (:B {name: 'b'}), (:B {name: 'b'})] | true   |
       | [(:B {name: 'b'})]                                     | false  |
       | [(:B {name: 'b'}), (:A {name: 'a'})]                   | true   |
       | [(:B {name: 'b'}), (:A {name: 'a'}), (:A {name: 'a'})] | true   |
       | [(:B {name: 'b'}), (:A {name: 'a'}), (:B {name: 'b'})] | true   |
       | [(:B {name: 'b'}), (:B {name: 'b'})]                   | false  |
       | [(:B {name: 'b'}), (:B {name: 'b'}), (:A {name: 'a'})] | true   |
       | [(:B {name: 'b'}), (:B {name: 'b'}), (:B {name: 'b'})] | false  |
      Step failed:
      Defined: tests/tck/features/expressions/quantifier/Quantifier3.feature:220:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 2 has no matching expected row: Record { columns: ["nodes", "result"], values: {"nodes": List([Node(NodeValue { id: 5, labels: ["A"], properties: {"name": String("a")} })]), "result": Boolean(true)} }
  Scenario: [9] Any quantifier on list containing relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | relationships                                             | result |
       | []                                                        | false  |
       | [[:RA {name: 'a'}]]                                       | true   |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}]]                    | true   |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}], [:RA {name: 'a'}]] | true   |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}], [:RB {name: 'b'}]] | true   |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}]]                    | true   |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}], [:RA {name: 'a'}]] | true   |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}], [:RB {name: 'b'}]] | true   |
       | [[:RB {name: 'b'}]]                                       | false  |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}]]                    | true   |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}], [:RA {name: 'a'}]] | true   |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}], [:RB {name: 'b'}]] | true   |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}]]                    | false  |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}], [:RA {name: 'a'}]] | true   |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}], [:RB {name: 'b'}]] | false  |
   ✔  And no side effects
  Scenario Outline: [10] Any quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] Any quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] Any quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] Any quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [10] Any quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [10] Any quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [10] Any quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] Any quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] Any quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] Any quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [13] Any quantifier is false if the predicate is statically false and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [14] Any quantifier is true if the predicate is statically true and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [15] Fail any quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [15] Fail any quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [15] Fail any quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Quantifier4 - All quantifier
  Scenario: [1] All quantifier is always true on empty list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a    | b    | c    |
       | true | true | true |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier on list literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier on list literal containing integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier on list literal containing floats
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier on list literal containing strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] All quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] All quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] All quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] All quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] All quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] All quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] All quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [6] All quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] All quantifier on list literal containing lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] All quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] All quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] All quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] All quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] All quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] All quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] All quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [7] All quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [7] All quantifier on list literal containing maps
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [8] All quantifier on list containing nodes
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | nodes                                                  | result |
       | []                                                     | true   |
       | [(:A {name: 'a'})]                                     | true   |
       | [(:A {name: 'a'}), (:A {name: 'a'})]                   | true   |
       | [(:A {name: 'a'}), (:A {name: 'a'}), (:A {name: 'a'})] | true   |
       | [(:A {name: 'a'}), (:A {name: 'a'}), (:B {name: 'b'})] | false  |
       | [(:A {name: 'a'}), (:B {name: 'b'})]                   | false  |
       | [(:A {name: 'a'}), (:B {name: 'b'}), (:A {name: 'a'})] | false  |
       | [(:A {name: 'a'}), (:B {name: 'b'}), (:B {name: 'b'})] | false  |
       | [(:B {name: 'b'})]                                     | false  |
       | [(:B {name: 'b'}), (:A {name: 'a'})]                   | false  |
       | [(:B {name: 'b'}), (:A {name: 'a'}), (:A {name: 'a'})] | false  |
       | [(:B {name: 'b'}), (:A {name: 'a'}), (:B {name: 'b'})] | false  |
       | [(:B {name: 'b'}), (:B {name: 'b'})]                   | false  |
       | [(:B {name: 'b'}), (:B {name: 'b'}), (:A {name: 'a'})] | false  |
       | [(:B {name: 'b'}), (:B {name: 'b'}), (:B {name: 'b'})] | false  |
      Step failed:
      Defined: tests/tck/features/expressions/quantifier/Quantifier4.feature:220:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 2 has no matching expected row: Record { columns: ["nodes", "result"], values: {"nodes": List([Node(NodeValue { id: 5, labels: ["A"], properties: {"name": String("a")} })]), "result": Boolean(true)} }
  Scenario: [9] All quantifier on list containing relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | relationships                                             | result |
       | []                                                        | true   |
       | [[:RA {name: 'a'}]]                                       | true   |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}]]                    | true   |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}], [:RA {name: 'a'}]] | true   |
       | [[:RA {name: 'a'}], [:RA {name: 'a'}], [:RB {name: 'b'}]] | false  |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}]]                    | false  |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}], [:RA {name: 'a'}]] | false  |
       | [[:RA {name: 'a'}], [:RB {name: 'b'}], [:RB {name: 'b'}]] | false  |
       | [[:RB {name: 'b'}]]                                       | false  |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}]]                    | false  |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}], [:RA {name: 'a'}]] | false  |
       | [[:RB {name: 'b'}], [:RA {name: 'a'}], [:RB {name: 'b'}]] | false  |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}]]                    | false  |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}], [:RA {name: 'a'}]] | false  |
       | [[:RB {name: 'b'}], [:RB {name: 'b'}], [:RB {name: 'b'}]] | false  |
   ✔  And no side effects
  Scenario Outline: [10] All quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] All quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] All quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [10] All quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] All quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [10] All quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [10] All quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [10] All quantifier on lists containing nulls
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | null   |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [11] All quantifier with IS NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [12] All quantifier with IS NOT NULL predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [13] All quantifier is false if the predicate is statically false and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario: [14] All quantifier is true if the predicate is statically true and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [15] Fail all quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [15] Fail all quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
  Scenario Outline: [15] Fail all quantifier on type mismatch between list elements and predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then a SyntaxError should be raised at compile time: InvalidArgumentType
Feature: Quantifier5 - None quantifier interop
  Scenario Outline: [1] None quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] None quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] None quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] None quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] None quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] None quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] None quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] None quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] None quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier is equal the boolean negative of the any quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier is equal the boolean negative of the any quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier is equal the boolean negative of the any quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier is equal the boolean negative of the any quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier is equal the boolean negative of the any quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier is equal the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier is equal the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier is equal the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier is equal the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier is equal the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier is equal whether the size of the list filtered with same the predicate is zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier is equal whether the size of the list filtered with same the predicate is zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier is equal whether the size of the list filtered with same the predicate is zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier is equal whether the size of the list filtered with same the predicate is zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier is equal whether the size of the list filtered with same the predicate is zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
Feature: Quantifier6 - Single quantifier interop
  Scenario Outline: [1] Single quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] Single quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] Single quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] Single quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] Single quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] Single quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] Single quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] Single quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Single quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier is equal whether the size of the list filtered with same the predicate is one
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier is equal whether the size of the list filtered with same the predicate is one
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier is equal whether the size of the list filtered with same the predicate is one
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier is equal whether the size of the list filtered with same the predicate is one
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Single quantifier is equal whether the size of the list filtered with same the predicate is one
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
Feature: Quantifier7 - Any quantifier interop
  Scenario Outline: [1] Any quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] Any quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] Any quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] Any quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] Any quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] Any quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] Any quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] Any quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] Any quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier is true if the single or the all quantifier is true
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier is true if the single or the all quantifier is true
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier is true if the single or the all quantifier is true
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier is true if the single or the all quantifier is true
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] Any quantifier is true if the single or the all quantifier is true
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier is equal the boolean negative of the none quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier is equal the boolean negative of the none quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier is equal the boolean negative of the none quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier is equal the boolean negative of the none quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] Any quantifier is equal the boolean negative of the none quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier is equal the boolean negative of the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier is equal the boolean negative of the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier is equal the boolean negative of the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier is equal the boolean negative of the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] Any quantifier is equal the boolean negative of the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier is equal whether the size of the list filtered with same the predicate is grater zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier is equal whether the size of the list filtered with same the predicate is grater zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier is equal whether the size of the list filtered with same the predicate is grater zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier is equal whether the size of the list filtered with same the predicate is grater zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [6] Any quantifier is equal whether the size of the list filtered with same the predicate is grater zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
Feature: Quantifier8 - All quantifier interop
  Scenario Outline: [1] All quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] All quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] All quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] All quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] All quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] All quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [1] All quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [1] All quantifier can nest itself and other quantifiers on nested lists
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [2] All quantifier can nest itself and other quantifiers on the same list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier is equal the none quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier is equal the none quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier is equal the none quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier is equal the none quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] All quantifier is equal the none quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier is equal the boolean negative of the any quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier is equal the boolean negative of the any quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier is equal the boolean negative of the any quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier is equal the boolean negative of the any quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] All quantifier is equal the boolean negative of the any quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier is equal whether the size of the list filtered with same the predicate is equal the size of the unfiltered list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier is equal whether the size of the list filtered with same the predicate is equal the size of the unfiltered list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier is equal whether the size of the list filtered with same the predicate is equal the size of the unfiltered list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier is equal whether the size of the list filtered with same the predicate is equal the size of the unfiltered list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] All quantifier is equal whether the size of the list filtered with same the predicate is equal the size of the unfiltered list
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
Feature: Quantifier9 - None quantifier invariants
  Scenario: [1] None quantifier is always true if the predicate is statically false and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario: [2] None quantifier is always false if the predicate is statically true and the list is not empty
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | false  |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier is always equal the boolean negative of the any quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier is always equal the boolean negative of the any quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier is always equal the boolean negative of the any quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier is always equal the boolean negative of the any quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [3] None quantifier is always equal the boolean negative of the any quantifier
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier is always equal the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier is always equal the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier is always equal the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier is always equal the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [4] None quantifier is always equal the all quantifier on the boolean negative of the predicate
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier is always equal whether the size of the list filtered with same the predicate is zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier is always equal whether the size of the list filtered with same the predicate is zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier is always equal whether the size of the list filtered with same the predicate is zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier is always equal whether the size of the list filtered with same the predicate is zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
  Scenario Outline: [5] None quantifier is always equal whether the size of the list filtered with same the predicate is zero
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | true   |
   ✔  And no side effects
Feature: String1 - Substring extraction
  Scenario: [1] `substring()` with default second argument
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | s           |
       | '123456789' |
   ✔  And no side effects
Feature: String10 - Exact Substring Search
  Scenario: [1] Finding exact matches with non-proper substring
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
   ✔  And no side effects
  Scenario: [2] Finding substring of string
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
   ✔  And no side effects
  Scenario: [3] Finding the empty substring
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
       | (:TheLabel {name: 'AB'})     |
       | (:TheLabel {name: 'abcdef'}) |
       | (:TheLabel {name: 'ab'})     |
       | (:TheLabel {name: ''})       |
   ✔  And no side effects
  Scenario: [4] Finding strings containing whitespace
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name      |
       | 'Foo Foo' |
   ✔  And no side effects
  Scenario: [5] Finding strings containing newline
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name       |
       | 'Foo\nFoo' |
   ✔  And no side effects
  Scenario: [6] No string contains null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
   ✔  And no side effects
  Scenario: [7] No string does not contain null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
   ✔  And no side effects
  Scenario: [8] Handling non-string operands for CONTAINS
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | v    | count(*) |
       | null | 36       |
   ✔  And no side effects
  Scenario: [9] NOT with CONTAINS
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
       | (:TheLabel {name: 'AB'})     |
       | (:TheLabel {name: ''})       |
   ✔  And no side effects
Feature: String11 - Combining Exact String Search
  Scenario: [1] Combining prefix and suffix search
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'abcdef'}) |
   ✔  And no side effects
  Scenario: [2] Combining prefix, suffix, and substring search
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
   ✔  And no side effects
Feature: String3 - String Reversal
  Scenario: [1] `reverse()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | reverse('raksO') |
       | 'Oskar'          |
   ✔  And no side effects
Feature: String4 - String Splitting
  Scenario: [1] `split()`
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | item |
       | 2    |
   ✔  And no side effects
Feature: String8 - Exact String Prefix Search
  Scenario: [1] Finding exact matches with non-proper prefix
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
   ✔  And no side effects
  Scenario: [2] Finding beginning of string
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
   ✔  And no side effects
  Scenario: [3] Finding the empty prefix
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
       | (:TheLabel {name: 'AB'})     |
       | (:TheLabel {name: 'abcdef'}) |
       | (:TheLabel {name: 'ab'})     |
       | (:TheLabel {name: ''})       |
   ✔  And no side effects
  Scenario: [4] Finding strings starting with whitespace
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name    |
       | ' Foo ' |
   ✔  And no side effects
  Scenario: [5] Finding strings starting with newline
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name      |
       | '\nFoo\n' |
   ✔  And no side effects
  Scenario: [6] No string starts with null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
   ✔  And no side effects
  Scenario: [7] No string does not start with null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
   ✔  And no side effects
  Scenario: [8] Handling non-string operands for STARTS WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | v    | count(*) |
       | null | 36       |
   ✔  And no side effects
  Scenario: [9] NOT with STARTS WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
       | (:TheLabel {name: 'AB'})     |
       | (:TheLabel {name: ''})       |
   ✔  And no side effects
Feature: String9 - Exact String Suffix Search
  Scenario: [1] Finding exact matches with non-proper suffix
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                        |
       | (:TheLabel {name: 'AB'}) |
   ✔  And no side effects
  Scenario: [2] Finding end of string
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
   ✔  And no side effects
  Scenario: [3] Finding the empty suffix
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
       | (:TheLabel {name: 'AB'})     |
       | (:TheLabel {name: 'abcdef'}) |
       | (:TheLabel {name: 'ab'})     |
       | (:TheLabel {name: ''})       |
   ✔  And no side effects
  Scenario: [4] Finding strings ending with whitespace
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name    |
       | ' Foo ' |
   ✔  And no side effects
  Scenario: [5] Finding strings ending with newline
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name      |
       | '\nFoo\n' |
   ✔  And no side effects
  Scenario: [6] No string ends with null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
   ✔  And no side effects
  Scenario: [7] No string does not end with null
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a |
   ✔  And no side effects
  Scenario: [8] Handling non-string operands for ENDS WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | v    | count(*) |
       | null | 36       |
   ✔  And no side effects
  Scenario: [9] NOT with ENDS WITH
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | a                            |
       | (:TheLabel {name: 'ABCDEF'}) |
       | (:TheLabel {name: 'AB'})     |
       | (:TheLabel {name: 'ab'})     |
       | (:TheLabel {name: ''})       |
   ✔  And no side effects
Feature: Temporal1 - Create Temporal Values from a Map
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1816-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1816-12-23' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1816-12-30' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1817-03-03' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1817-07-21' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1817-12-22' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1817-12-29' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1818-12-21' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1818-12-28' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1819-01-04' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1819-12-27' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1816-12-31' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1817-01-08' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1817-01-07' |
   ✔  And no side effects
  Scenario Outline: [1] Should construct week date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d            |
       | '1817-01-07' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1816-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1816-12-23T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1816-12-30T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1817-03-03T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1817-07-21T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1817-12-22T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1817-12-29T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1818-12-21T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1818-12-28T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1819-01-04T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1819-12-27T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1816-12-31T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1817-01-08T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1817-01-07T00:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should construct week localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                  |
       | '1817-01-07T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1816-01-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1816-12-23T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1816-12-30T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1817-03-03T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1817-07-21T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1817-12-22T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1817-12-29T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1818-12-21T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1818-12-28T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1819-01-04T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1819-12-27T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1816-12-31T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1817-01-08T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1817-01-07T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should construct week datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d                   |
       | '1817-01-07T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [4] Should construct date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-11' |
   ✔  And no side effects
  Scenario Outline: [4] Should construct date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-01' |
   ✔  And no side effects
  Scenario Outline: [4] Should construct date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-03-07' |
   ✔  And no side effects
  Scenario Outline: [4] Should construct date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-03-05' |
   ✔  And no side effects
  Scenario Outline: [4] Should construct date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-01' |
   ✔  And no side effects
  Scenario Outline: [4] Should construct date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-07-20' |
   ✔  And no side effects
  Scenario Outline: [4] Should construct date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-08-14' |
   ✔  And no side effects
  Scenario Outline: [4] Should construct date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-07-01' |
   ✔  And no side effects
  Scenario Outline: [5] Should construct local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.123456789' |
   ✔  And no side effects
  Scenario Outline: [5] Should construct local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [5] Should construct local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result            |
       | '12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [5] Should construct local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result         |
       | '12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [5] Should construct local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result     |
       | '12:31:14' |
   ✔  And no side effects
  Scenario Outline: [5] Should construct local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:31' |
   ✔  And no side effects
  Scenario Outline: [5] Should construct local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.123456789Z' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.000000003Z' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '12:31:14.645876Z' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result          |
       | '12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result      |
       | '12:31:14Z' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | '12:31Z' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | '12:00Z' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                  |
       | '12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645+01:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | '12:31:14+01:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:31+01:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should construct time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.123456789' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.000000003' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-10-11T12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-10-11T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-11T12:31:14' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:31' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T00:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-03-07T12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-03-07T12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-03-07T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-03-07T12:31:14' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-03-07T12:31' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-03-07T12:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-03-07T00:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-07-20T12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-07-20T12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-07-20T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-07-20T12:31:14' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-07-20T12:31' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-07-20T12:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-07-20T00:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-08-14T12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-08-14T12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-08-14T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-08-14T12:31:14' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-08-14T12:31' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-08-14T12:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-08-14T00:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should construct local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:31:14.123456789Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                        |
       | '1984-10-11T12:31:14.645876Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-10-11T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-10-11T12:31:14Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-11T12:31Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-11T12:00Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-11T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-03-07T12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                        |
       | '1984-03-07T12:31:14.645876Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-03-07T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-03-07T12:31:14Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-03-07T12:31Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-03-07T12:00Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-03-07T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-07-20T12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                        |
       | '1984-07-20T12:31:14.645876Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-07-20T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-07-20T12:31:14Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-07-20T12:31Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-07-20T12:00Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-07-20T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-08-14T12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                        |
       | '1984-08-14T12:31:14.645876Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-08-14T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-08-14T12:31:14Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-08-14T12:31Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-08-14T12:00Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-08-14T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should construct date time with default time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-01-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-10-11T12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-11T12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                      |
       | '1984-10-11T12:31:14+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-11T12:31+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-11T12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-11T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-03-07T12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-03-07T12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-03-07T12:31:14.645+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                      |
       | '1984-03-07T12:31:14+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-03-07T12:31+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-03-07T12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-03-07T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-07-20T12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-07-20T12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-07-20T12:31:14.645+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                      |
       | '1984-07-20T12:31:14+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-07-20T12:31+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-07-20T12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-07-20T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-08-14T12:31:14.645876123+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-08-14T12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-08-14T12:31:14.645+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                      |
       | '1984-08-14T12:31:14+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-08-14T12:31+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-08-14T12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-08-14T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should construct date time with offset time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-01-01T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                                  |
       | '1984-10-11T12:31:14.645876123+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                               |
       | '1984-10-11T12:31:14.645876+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '1984-10-11T12:31:14.645+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-11T12:31:14+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:31+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                                  |
       | '1984-03-07T12:31:14.645876123+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                               |
       | '1984-03-07T12:31:14.645876+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '1984-03-07T12:31:14.645+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-03-07T12:31:14+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-03-07T12:31+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-03-07T12:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-03-07T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                                  |
       | '1984-07-20T12:31:14.645876123+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                               |
       | '1984-07-20T12:31:14.645876+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '1984-07-20T12:31:14.645+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-07-20T12:31:14+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-07-20T12:31+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-07-20T12:00+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-07-20T00:00+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                                  |
       | '1984-08-14T12:31:14.645876123+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                               |
       | '1984-08-14T12:31:14.645876+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '1984-08-14T12:31:14.645+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-08-14T12:31:14+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-08-14T12:31+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-08-14T12:00+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-08-14T00:00+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should construct date time with named time zone
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario: [11] Should construct date time from epoch
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d1                               | d2                         |
       | '1970-01-05T19:46:19.999999999Z' | '1977-07-15T13:34:33.987Z' |
   ✔  And no side effects
  Scenario Outline: [12] Should construct duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | 'P14DT16H12M' |
   ✔  And no side effects
  Scenario Outline: [12] Should construct duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result      |
       | 'P5M1DT12H' |
   ✔  And no side effects
  Scenario Outline: [12] Should construct duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | 'P22DT19H51M49.5S' |
   ✔  And no side effects
  Scenario Outline: [12] Should construct duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result     |
       | 'P17DT12H' |
   ✔  And no side effects
  Scenario Outline: [12] Should construct duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | 'P12Y5M14DT16H13M10S' |
   ✔  And no side effects
  Scenario Outline: [12] Should construct duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | 'P14DT1M10.001S' |
   ✔  And no side effects
  Scenario Outline: [12] Should construct duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | 'P14DT1M10.000001S' |
   ✔  And no side effects
  Scenario Outline: [12] Should construct duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | 'P14DT1M10.000000001S' |
   ✔  And no side effects
  Scenario Outline: [12] Should construct duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result    |
       | 'PT1M31S' |
   ✔  And no side effects
  Scenario Outline: [13] Should construct temporal with time offset with second precision
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | '12:34:56+02:05' |
   ✔  And no side effects
  Scenario Outline: [13] Should construct temporal with time offset with second precision
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '12:34:56+02:05:59' |
   ✔  And no side effects
  Scenario Outline: [13] Should construct temporal with time offset with second precision
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '12:34:56-02:05:07' |
   ✔  And no side effects
  Scenario Outline: [13] Should construct temporal with time offset with second precision
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                         |
       | '1984-10-11T12:34:56+02:05:59' |
   ✔  And no side effects
Feature: Temporal10 - Compute Durations Between two Temporal Values
  Scenario Outline: [1] Should split between boundaries correctly
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | dur     | dur.days | dur.seconds | dur.nanosecondsOfSecond |
       | 'PT22H' | 0        | 79200       | 0                       |
   ✔  And no side effects
  Scenario Outline: [1] Should split between boundaries correctly
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | dur      | dur.days | dur.seconds | dur.nanosecondsOfSecond |
       | 'PT-22H' | 0        | -79200      | 0                       |
   ✔  And no side effects
  Scenario Outline: [1] Should split between boundaries correctly
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | dur             | dur.days | dur.seconds | dur.nanosecondsOfSecond |
       | 'PT23H59M59.9S' | 0        | 86399       | 900000000               |
   ✔  And no side effects
  Scenario Outline: [1] Should split between boundaries correctly
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | dur                | dur.days | dur.seconds | dur.nanosecondsOfSecond |
       | 'PT-23H-59M-59.9S' | 0        | -86400      | 100000000               |
   ✔  And no side effects
  Scenario Outline: [1] Should split between boundaries correctly
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | dur    | dur.days | dur.seconds | dur.nanosecondsOfSecond |
       | 'PT6H' | 0        | 21600       | 0                       |
   ✔  And no side effects
  Scenario Outline: [1] Should split between boundaries correctly
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | dur     | dur.days | dur.seconds | dur.nanosecondsOfSecond |
       | 'PT-6H' | 0        | -21600      | 0                       |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration    |
       | 'P30Y8M13D' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration                  |
       | 'P31Y9M10DT21H45M22.142S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration                  |
       | 'P30Y9M10DT21H40M32.142S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration   |
       | 'PT16H30M' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration   |
       | 'PT16H30M' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration     |
       | 'PT-14H-30M' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration         |
       | 'PT7H15M22.142S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration         |
       | 'PT7H10M32.142S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT2H'   |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT2H'   |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration     |
       | 'PT-14H-30M' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration         |
       | 'PT7H15M22.142S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration         |
       | 'PT6H10M32.142S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT2H'   |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT1H'   |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration                 |
       | 'P-27DT-21H-40M-32.142S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration    |
       | 'P1YT4M50S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT-5H-10M-32.142S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT-5H-10M-32.142S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration              |
       | 'P11M2DT2H19M23.857S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration        |
       | 'P2YT4M45.999S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration         |
       | 'P1YT59M55.999S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT-5H-10M-36.143S' |
   ✔  And no side effects
  Scenario Outline: [2] Should compute duration between two temporals
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT-4H-10M-36.143S' |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P30Y8M' |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P31Y9M' |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P30Y9M' |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P1Y'    |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P11M'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P2Y'    |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P1Y'    |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [3] Should compute duration between two temporals in months
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration  |
       | 'P11213D' |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration  |
       | 'P11606D' |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration  |
       | 'P11240D' |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P-27D'  |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P366D'  |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P337D'  |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P731D'  |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P365D'  |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [4] Should compute duration between two temporals in days
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration    |
       | 'PT269112H' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration              |
       | 'PT278565H45M22.142S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration              |
       | 'PT269781H40M32.142S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration   |
       | 'PT16H30M' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration   |
       | 'PT16H30M' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration     |
       | 'PT-14H-30M' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration         |
       | 'PT7H15M22.142S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration         |
       | 'PT7H10M32.142S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT2H'   |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT2H'   |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration     |
       | 'PT-14H-30M' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration         |
       | 'PT7H15M22.142S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration         |
       | 'PT6H10M32.142S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT2H'   |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT1H'   |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration              |
       | 'PT-669H-40M-32.142S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration       |
       | 'PT8784H4M50S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT-5H-10M-32.142S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT-5H-10M-32.142S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT8090H19M23.857S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT17544H4M45.999S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT8760H59M55.999S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT-5H-10M-36.143S' |
   ✔  And no side effects
  Scenario Outline: [5] Should compute duration between two temporals in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration            |
       | 'PT-4H-10M-36.143S' |
   ✔  And no side effects
  Scenario: [6] Should compute duration between if they differ only by a fraction of a second and the first comes after the second.
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d           |
       | 'PT-0.001S' |
   ✔  And no side effects
  Scenario Outline: [7] Should compute negative duration between in big units
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration  |
       | 'P-1Y-8M' |
   ✔  And no side effects
  Scenario Outline: [7] Should compute negative duration between in big units
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration   |
       | 'P-1Y-11M' |
   ✔  And no side effects
  Scenario Outline: [7] Should compute negative duration between in big units
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P-2Y'   |
   ✔  And no side effects
  Scenario Outline: [7] Should compute negative duration between in big units
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'P-2Y'   |
   ✔  And no side effects
  Scenario Outline: [7] Should compute negative duration between in big units
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration    |
       | 'P-33Y-11M' |
   ✔  And no side effects
  Scenario Outline: [8] Should handle durations at daylight saving time day
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT5H'   |
   ✔  And no side effects
  Scenario Outline: [8] Should handle durations at daylight saving time day
   ✔  Given any graph
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | duration |
       | 'PT5H'   |
      Step failed:
      Defined: tests/tck/features/expressions/temporal/Temporal10.feature:238:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["duration"], values: {"duration": Duration(DurationValue { months: 0, days: 0, seconds: -1509213600, nanos: 0 })} }
  Scenario Outline: [8] Should handle durations at daylight saving time day
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT5H'   |
   ✔  And no side effects
  Scenario Outline: [8] Should handle durations at daylight saving time day
   ✔  Given any graph
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | duration |
       | 'PT5H'   |
      Step failed:
      Defined: tests/tck/features/expressions/temporal/Temporal10.feature:238:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["duration"], values: {"duration": Duration(DurationValue { months: 0, days: 0, seconds: 1509246000, nanos: 0 })} }
  Scenario Outline: [8] Should handle durations at daylight saving time day
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT5H'   |
   ✔  And no side effects
  Scenario Outline: [8] Should handle durations at daylight saving time day
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT25H'  |
   ✔  And no side effects
  Scenario: [9] Should handle large durations
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration             |
       | 'P1999999998Y11M30D' |
   ✔  And no side effects
  Scenario: [10] Should handle large durations in seconds
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration                  |
       | 'PT17531639991215H59M59S' |
   ✔  And no side effects
  Scenario Outline: [11] Should handle when seconds and subseconds have different signs
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration  |
       | 'PT-0.4S' |
   ✔  And no side effects
  Scenario Outline: [11] Should handle when seconds and subseconds have different signs
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0.4S' |
   ✔  And no side effects
  Scenario Outline: [11] Should handle when seconds and subseconds have different signs
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0.6S' |
   ✔  And no side effects
  Scenario Outline: [11] Should handle when seconds and subseconds have different signs
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration    |
       | 'PT10M0.6S' |
   ✔  And no side effects
  Scenario Outline: [11] Should handle when seconds and subseconds have different signs
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration      |
       | 'PT-9M-59.4S' |
   ✔  And no side effects
  Scenario Outline: [11] Should handle when seconds and subseconds have different signs
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration  |
       | 'PT-0.3S' |
   ✔  And no side effects
  Scenario Outline: [11] Should handle when seconds and subseconds have different signs
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration    |
       | 'PT9M59.7S' |
   ✔  And no side effects
  Scenario Outline: [11] Should handle when seconds and subseconds have different signs
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration      |
       | 'PT-10M-0.3S' |
   ✔  And no side effects
  Scenario Outline: [11] Should handle when seconds and subseconds have different signs
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration  |
       | 'PT-1.6S' |
   ✔  And no side effects
  Scenario Outline: [11] Should handle when seconds and subseconds have different signs
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT1.6S' |
   ✔  And no side effects
  Scenario Outline: [12] Should compute durations with no difference
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [12] Should compute durations with no difference
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [12] Should compute durations with no difference
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [12] Should compute durations with no difference
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [12] Should compute durations with no difference
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | duration |
       | 'PT0S'   |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
Feature: Temporal2 - Create Temporal Values from a String
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-07-21' |
   ✔  And no side effects
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-07-21' |
   ✔  And no side effects
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-07-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-07-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-07-21' |
   ✔  And no side effects
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-07-21' |
   ✔  And no side effects
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-07-20' |
   ✔  And no side effects
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-07-20' |
   ✔  And no side effects
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-07-21' |
   ✔  And no side effects
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-07-21' |
   ✔  And no side effects
  Scenario Outline: [1] Should parse date from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2015-01-01' |
   ✔  And no side effects
  Scenario Outline: [2] Should parse local time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result         |
       | '21:40:32.142' |
   ✔  And no side effects
  Scenario Outline: [2] Should parse local time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result         |
       | '21:40:32.142' |
   ✔  And no side effects
  Scenario Outline: [2] Should parse local time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result     |
       | '21:40:32' |
   ✔  And no side effects
  Scenario Outline: [2] Should parse local time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result     |
       | '21:40:32' |
   ✔  And no side effects
  Scenario Outline: [2] Should parse local time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '21:40' |
   ✔  And no side effects
  Scenario Outline: [2] Should parse local time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '21:40' |
   ✔  And no side effects
  Scenario Outline: [2] Should parse local time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '21:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should parse time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '21:40:32.142+01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should parse time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result          |
       | '21:40:32.142Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should parse time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | '21:40:32+01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should parse time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | '21:40:32-01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should parse time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '21:40-01:30' |
   ✔  And no side effects
  Scenario Outline: [3] Should parse time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | '21:40Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should parse time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '21:40-02:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should parse time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '22:00+18:00' |
   ✔  And no side effects
  Scenario Outline: [4] Should parse local date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '2015-07-21T21:40:32.142' |
   ✔  And no side effects
  Scenario Outline: [4] Should parse local date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '2015-07-21T21:40:32.142' |
   ✔  And no side effects
  Scenario Outline: [4] Should parse local date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '2015-07-21T21:40:32' |
   ✔  And no side effects
  Scenario Outline: [4] Should parse local date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '2015-01-01T21:40:32' |
   ✔  And no side effects
  Scenario Outline: [4] Should parse local date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '2015-07-21T21:40' |
   ✔  And no side effects
  Scenario Outline: [4] Should parse local date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '2015-07-20T21:40' |
   ✔  And no side effects
  Scenario Outline: [4] Should parse local date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '2015-07-21T21:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should parse date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '2015-07-21T21:40:32.142+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should parse date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '2015-07-21T21:40:32.142Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should parse date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                      |
       | '2015-07-21T21:40:32+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should parse date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                      |
       | '2015-01-01T21:40:32-01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should parse date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '2015-07-21T21:40-01:30' |
   ✔  And no side effects
  Scenario Outline: [5] Should parse date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '2015-07-20T21:40Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should parse date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '2015-07-20T21:40-02:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should parse date time from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '2015-07-21T21:00+18:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should parse date time with named time zone from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '2015-07-21T21:40:32.142+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [6] Should parse date time with named time zone from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                           |
       | '2015-07-21T21:40:32.142+08:45[Australia/Eucla]' |
   ✔  And no side effects
  Scenario Outline: [6] Should parse date time with named time zone from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '2015-07-21T21:40:32.142-04:00[America/New_York]' |
   ✔  And no side effects
  Scenario Outline: [6] Should parse date time with named time zone from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                         |
       | '2015-07-21T21:40:32.142+01:00[Europe/London]' |
   ✔  And no side effects
  Scenario Outline: [6] Should parse date time with named time zone from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                               |
       | '1818-07-21T21:40:32.142+00:53:28[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [7] Should parse duration from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | 'P14DT16H12M' |
   ✔  And no side effects
  Scenario Outline: [7] Should parse duration from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result      |
       | 'P5M1DT12H' |
   ✔  And no side effects
  Scenario Outline: [7] Should parse duration from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | 'P22DT19H51M49.5S' |
   ✔  And no side effects
  Scenario Outline: [7] Should parse duration from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | 'PT45S' |
   ✔  And no side effects
  Scenario Outline: [7] Should parse duration from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result     |
       | 'P17DT12H' |
   ✔  And no side effects
  Scenario Outline: [7] Should parse duration from string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | 'P12Y5M14DT16H13M10S' |
   ✔  And no side effects
  Scenario Outline: [7] Should parse duration from string
   ✔  Given any graph
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | result                     |
       | 'P2012Y2M2DT14H37M21.545S' |
      Step failed:
      Defined: tests/tck/features/expressions/temporal/Temporal2.feature:169:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["result"], values: {"result": Duration(DurationValue { months: 0, days: 0, seconds: 0, nanos: 0 })} }
Feature: Temporal3 - Project Temporal Values from other Temporal Values
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-11-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-11-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '0028-11-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-11-28' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-08' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-28' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-08-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-11-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-11-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '0028-11-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-11-28' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-08' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-28' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-08-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-11-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-11-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '0028-11-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-11-28' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-08' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-28' |
   ✔  And no side effects
  Scenario Outline: [1] Should select date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-08-11' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:42.645876123' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result            |
       | '12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result            |
       | '12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result            |
       | '12:31:42.645876' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result         |
       | '12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result         |
       | '12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result         |
       | '12:31:42.645' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should select local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result     |
       | '12:00:42' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:14.645876123+05:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:42.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:42.645876123+05:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                  |
       | '12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                  |
       | '12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                  |
       | '16:31:14.645876+05:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                  |
       | '12:31:42.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                  |
       | '16:31:42.645876+05:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result          |
       | '12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result          |
       | '12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645+05:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result          |
       | '12:31:42.645Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:42.645+05:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '16:00+05:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | '12:00:42+01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should select time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | '16:00:42+05:00' |
   ✔  And no side effects
  Scenario Outline: [4] Should select date into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-11T10:10:10' |
   ✔  And no side effects
  Scenario Outline: [4] Should select date into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-28T10:10:10' |
   ✔  And no side effects
  Scenario Outline: [4] Should select date into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-03-07T10:10:10' |
   ✔  And no side effects
  Scenario Outline: [4] Should select date into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-03-28T10:10:10' |
   ✔  And no side effects
  Scenario Outline: [4] Should select date into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-11T10:10:10' |
   ✔  And no side effects
  Scenario Outline: [4] Should select date into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-28T10:10:10' |
   ✔  And no side effects
  Scenario Outline: [5] Should select time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [5] Should select time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:42.645876123' |
   ✔  And no side effects
  Scenario Outline: [5] Should select time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-10-11T12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [5] Should select time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-10-11T12:31:42.645876' |
   ✔  And no side effects
  Scenario Outline: [5] Should select time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-10-11T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [5] Should select time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-10-11T12:31:42.645' |
   ✔  And no side effects
  Scenario Outline: [5] Should select time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should select time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-11T12:00:42' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-28T12:31:42.645876123' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-10-11T12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-10-28T12:31:42.645876' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-10-11T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-10-28T12:31:42.645' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-28T12:00:42' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-03-07T12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-03-28T12:31:42.645876123' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-03-07T12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-03-28T12:31:42.645876' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-03-07T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-03-28T12:31:42.645' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-03-07T12:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-03-28T12:00:42' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645876123' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-28T12:31:42.645876123' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-10-11T12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-10-28T12:31:42.645876' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-10-11T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-10-28T12:31:42.645' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should select date and time into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-28T12:00:42' |
   ✔  And no side effects
  Scenario Outline: [7] Should select datetime into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-03-07T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [7] Should select datetime into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-03-07T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [7] Should select datetime into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-03-28T12:31:42.645' |
   ✔  And no side effects
  Scenario Outline: [7] Should select datetime into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should select datetime into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:00' |
   ✔  And no side effects
  Scenario Outline: [7] Should select datetime into local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-28T12:00:42' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-10-11T10:10:10Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                      |
       | '1984-10-11T10:10:10+05:00' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-10-28T10:10:10Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-28T10:10:10-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-03-07T10:10:10Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                      |
       | '1984-03-07T10:10:10+05:00' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-03-28T10:10:10Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-03-28T10:10:10-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-10-11T10:10:10Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                      |
       | '1984-10-11T10:10:10+05:00' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-10-28T10:10:10Z' |
   ✔  And no side effects
  Scenario Outline: [8] Should select date into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-28T10:10:10-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-10-11T12:31:14.645876123+05:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:31:42.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                                  |
       | '1984-10-11T12:31:42.645876123-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-11T12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-11T16:31:14.645876+05:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-11T12:31:42.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                               |
       | '1984-10-11T01:31:42.645876-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-10-11T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645+05:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-10-11T12:31:42.645Z' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '1984-10-11T12:31:42.645-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-11T16:00+05:00' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-11T12:00:42+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [9] Should select time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-11T01:00:42-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-10-11T12:31:14.645876123+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-28T12:31:42.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                                  |
       | '1984-10-28T12:31:42.645876123-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-11T12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-11T16:31:14.645876+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-28T12:31:42.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                               |
       | '1984-10-28T01:31:42.645876-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-10-11T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-10-28T12:31:42.645Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '1984-10-28T12:31:42.645-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-11T16:00+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-28T12:00:42+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-28T01:00:42-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-03-07T12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-03-07T12:31:14.645876123+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-03-28T12:31:42.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                                  |
       | '1984-03-28T12:31:42.645876123-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-03-07T12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-03-07T16:31:14.645876+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-03-28T12:31:42.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                               |
       | '1984-03-28T01:31:42.645876-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-03-07T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-03-07T12:31:14.645+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-03-28T12:31:42.645Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '1984-03-28T12:31:42.645-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-03-07T12:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-03-07T16:00+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-03-28T12:00:42+02:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-03-28T00:00:42-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:31:14.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-10-11T12:31:14.645876123+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-28T12:31:42.645876123Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                                  |
       | '1984-10-28T12:31:42.645876123-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-11T12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-11T16:31:14.645876+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-28T12:31:42.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                               |
       | '1984-10-28T01:31:42.645876-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-10-11T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-10-28T12:31:42.645Z' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '1984-10-28T12:31:42.645-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-11T16:00+05:00' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-28T12:00:42+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [10] Should select date and time into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-28T01:00:42-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [11] Should datetime into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-03-07T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [11] Should datetime into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-03-07T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [11] Should datetime into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-03-07T12:31:14.645+05:00' |
   ✔  And no side effects
  Scenario Outline: [11] Should datetime into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-03-28T12:31:42.645Z' |
   ✔  And no side effects
  Scenario Outline: [11] Should datetime into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                            |
       | '1984-03-28T12:31:42.645-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
  Scenario Outline: [11] Should datetime into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [11] Should datetime into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [11] Should datetime into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-11T16:00+05:00' |
   ✔  And no side effects
  Scenario Outline: [11] Should datetime into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-28T12:00:42+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [11] Should datetime into date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                        |
       | '1984-10-28T01:00:42-10:00[Pacific/Honolulu]' |
   ✔  And no side effects
Feature: Temporal4 - Store Temporal Values
  Scenario Outline: [1] Should store date
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.created    |
       | '1984-10-11' |
  Scenario Outline: [2] Should store date array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates        |
       | ['1984-10-12'] |
  Scenario Outline: [2] Should store date array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates                                    |
       | ['1984-10-13', '1984-10-14', '1984-10-15'] |
  Scenario Outline: [3] Should store local time
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.created |
       | '12:00'   |
  Scenario Outline: [4] Should store local time array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates   |
       | ['13:00'] |
  Scenario Outline: [4] Should store local time array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates                     |
       | ['14:00', '15:00', '16:00'] |
  Scenario Outline: [5] Should store time
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.created |
       | '12:00Z'  |
  Scenario Outline: [6] Should store time array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates    |
       | ['13:00Z'] |
  Scenario Outline: [6] Should store time array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates                        |
       | ['14:00Z', '15:00Z', '16:00Z'] |
  Scenario Outline: [7] Should store local date time
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.created          |
       | '1912-01-01T00:00' |
  Scenario Outline: [8] Should store local date time array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates              |
       | ['1913-01-01T00:00'] |
  Scenario Outline: [8] Should store local date time array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates                                                      |
       | ['1914-01-01T00:00', '1915-01-01T00:00', '1916-01-01T00:00'] |
  Scenario Outline: [9] Should store date time
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.created           |
       | '1912-01-01T00:00Z' |
  Scenario Outline: [10] Should store date time array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates               |
       | ['1913-01-01T00:00Z'] |
  Scenario Outline: [10] Should store date time array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates                                                         |
       | ['1914-01-01T00:00Z', '1915-01-01T00:00Z', '1916-01-01T00:00Z'] |
  Scenario Outline: [11] Should store duration
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.created |
       | 'PT12S'   |
  Scenario Outline: [12] Should store duration array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates   |
       | ['PT13S'] |
  Scenario Outline: [12] Should store duration array
   ✔  Given an empty graph
   ✔  When executing query:
   ✔  Then the result should be empty
   ✔  And the side effects should be:
       | +nodes      | 1 |
       | +properties | 1 |
   ✔  When executing control query:
   ✔  Then the result should be, in any order:
       | n.dates                     |
       | ['PT14S', 'PT15S', 'PT16S'] |
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
  Scenario Outline: [13] Should propagate null
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | t    |
       | null |
   ✔  And no side effects
Feature: Temporal5 - Access Components of Temporal Values
  Scenario: [1] Should provide accessors for date
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d.year | d.quarter | d.month | d.week | d.weekYear | d.day | d.ordinalDay | d.weekDay | d.dayOfQuarter |
       | 1984   | 4         | 10      | 41     | 1984       | 11    | 285          | 4         | 11             |
   ✔  And no side effects
  Scenario: [2] Should provide accessors for date in last weekYear
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d.year | d.weekYear | d.week | d.weekDay |
       | 1984   | 1983       | 52     | 7         |
   ✔  And no side effects
  Scenario: [3] Should provide accessors for local time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d.hour | d.minute | d.second | d.millisecond | d.microsecond | d.nanosecond |
       | 12     | 31       | 14       | 645           | 645876        | 645876123    |
   ✔  And no side effects
  Scenario: [4] Should provide accessors for time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d.hour | d.minute | d.second | d.millisecond | d.microsecond | d.nanosecond | d.timezone | d.offset | d.offsetMinutes | d.offsetSeconds |
       | 12     | 31       | 14       | 645           | 645876        | 645876123    | '+01:00'   | '+01:00' | 60              | 3600            |
   ✔  And no side effects
  Scenario: [5] Should provide accessors for local date time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d.year | d.quarter | d.month | d.week | d.weekYear | d.day | d.ordinalDay | d.weekDay | d.dayOfQuarter | d.hour | d.minute | d.second | d.millisecond | d.microsecond | d.nanosecond |
       | 1984   | 4         | 11      | 45     | 1984       | 11    | 316          | 7         | 42             | 12     | 31       | 14       | 645           | 645876        | 645876123    |
   ✔  And no side effects
  Scenario: [6] Should provide accessors for date time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d.year | d.quarter | d.month | d.week | d.weekYear | d.day | d.ordinalDay | d.weekDay | d.dayOfQuarter | d.hour | d.minute | d.second | d.millisecond | d.microsecond | d.nanosecond | d.timezone         | d.offset | d.offsetMinutes | d.offsetSeconds | d.epochSeconds | d.epochMillis |
       | 1984   | 4         | 11      | 45     | 1984       | 11    | 316          | 7         | 42             | 12     | 31       | 14       | 645           | 645876        | 645876123    | 'Europe/Stockholm' | '+01:00' | 60              | 3600            | 469020674      | 469020674645  |
   ✔  And no side effects
  Scenario: [7] Should provide accessors for duration
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | d.years | d.quarters | d.months | d.weeks | d.days | d.hours | d.minutes | d.seconds | d.milliseconds | d.microseconds | d.nanoseconds | d.quartersOfYear | d.monthsOfQuarter | d.monthsOfYear | d.daysOfWeek | d.minutesOfHour | d.secondsOfMinute | d.millisecondsOfSecond | d.microsecondsOfSecond | d.nanosecondsOfSecond |
       | 1       | 5          | 16       | 1       | 10     | 1       | 61        | 3661      | 3661111        | 3661111111     | 3661111111111 | 1                | 1                 | 4              | 3            | 1               | 1                 | 111                    | 111111                 | 111111111             |
   ✔  And no side effects
Feature: Temporal6 - Render Temporal Values as a String
  Scenario: [1] Should serialize date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts           | b    |
       | '1984-10-11' | true |
   ✔  And no side effects
  Scenario: [2] Should serialize local time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts                   | b    |
       | '12:31:14.645876123' | true |
   ✔  And no side effects
  Scenario: [3] Should serialize time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts                         | b    |
       | '12:31:14.645876123+01:00' | true |
   ✔  And no side effects
  Scenario: [4] Should serialize local date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts                              | b    |
       | '1984-10-11T12:31:14.645876123' | true |
   ✔  And no side effects
  Scenario: [5] Should serialize date time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts                                    | b    |
       | '1984-10-11T12:31:14.645876123+01:00' | true |
   ✔  And no side effects
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts                              | b    |
       | 'P12Y5M14DT16H13M10.000000001S' | true |
   ✔  And no side effects
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts               | b    |
       | 'P12Y5M-14DT16H' | true |
   ✔  And no side effects
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts      | b    |
       | 'PT11M' | true |
   ✔  And no side effects
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts         | b    |
       | 'PT1.999S' | true |
   ✔  And no side effects
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts          | b    |
       | 'PT-1.999S' | true |
   ✔  And no side effects
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | ts          | b    |
       | 'PT-2.001S' | true |
      Step failed:
      Defined: tests/tck/features/expressions/temporal/Temporal6.feature:100:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["ts", "b"], values: {"ts": String("PT-2.001S"), "b": Boolean(false)} }
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts           | b    |
       | 'P1DT0.001S' | true |
   ✔  And no side effects
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts            | b    |
       | 'P1DT-0.001S' | true |
   ✔  And no side effects
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts          | b    |
       | 'PT59.999S' | true |
   ✔  And no side effects
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts           | b    |
       | 'PT-59.999S' | true |
   ✔  And no side effects
  Scenario Outline: [6] Should serialize duration
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts             | b    |
       | 'PT-1M-0.001S' | true |
   ✔  And no side effects
  Scenario: [7] Should serialize timezones correctly
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | ts                                                      |
       | '2017-08-08T12:31:14.645876123+02:00[Europe/Stockholm]' |
   ✔  And no side effects
Feature: Temporal7 - Compare Temporal Values
  Scenario Outline: [1] Should compare dates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x > d | x < d | x >= d | x <= d | x = d |
       | false | true  | false  | true   | false |
   ✔  And no side effects
  Scenario Outline: [1] Should compare dates
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x > d | x < d | x >= d | x <= d | x = d |
       | false | false | true   | true   | true  |
   ✔  And no side effects
  Scenario Outline: [2] Should compare local times
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x > d | x < d | x >= d | x <= d | x = d |
       | false | true  | false  | true   | false |
   ✔  And no side effects
  Scenario Outline: [2] Should compare local times
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x > d | x < d | x >= d | x <= d | x = d |
       | false | false | true   | true   | true  |
   ✔  And no side effects
  Scenario Outline: [3] Should compare times
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x > d | x < d | x >= d | x <= d | x = d |
       | false | true  | false  | true   | false |
   ✔  And no side effects
  Scenario Outline: [3] Should compare times
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x > d | x < d | x >= d | x <= d | x = d |
       | false | false | true   | true   | true  |
   ✔  And no side effects
  Scenario Outline: [4] Should compare local date times
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x > d | x < d | x >= d | x <= d | x = d |
       | false | true  | false  | true   | false |
   ✔  And no side effects
  Scenario Outline: [4] Should compare local date times
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x > d | x < d | x >= d | x <= d | x = d |
       | false | false | true   | true   | true  |
   ✔  And no side effects
  Scenario Outline: [5] Should compare date times
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x > d | x < d | x >= d | x <= d | x = d |
       | false | true  | false  | true   | false |
   ✔  And no side effects
  Scenario Outline: [5] Should compare date times
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x > d | x < d | x >= d | x <= d | x = d |
       | false | false | true   | true   | true  |
   ✔  And no side effects
  Scenario Outline: [6] Should compare durations for equality
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x = d |
       | false |
   ✔  And no side effects
  Scenario Outline: [6] Should compare durations for equality
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x = d |
       | false |
   ✔  And no side effects
  Scenario Outline: [6] Should compare durations for equality
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x = d |
       | false |
   ✔  And no side effects
  Scenario Outline: [6] Should compare durations for equality
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x = d |
       | false |
   ✔  And no side effects
  Scenario Outline: [6] Should compare durations for equality
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x = d |
       | false |
   ✔  And no side effects
  Scenario Outline: [6] Should compare durations for equality
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x = d |
       | true  |
   ✔  And no side effects
  Scenario Outline: [6] Should compare durations for equality
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x = d |
       | true  |
   ✔  And no side effects
  Scenario Outline: [6] Should compare durations for equality
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | x = d |
       | false |
   ✔  And no side effects
Feature: Temporal8 - Compute Arithmetic Operations on Temporal Values
  Scenario Outline: [1] Should add or subtract duration to or from date
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum          | diff         |
       | '1997-03-25' | '1972-04-27' |
   ✔  And no side effects
  Scenario Outline: [1] Should add or subtract duration to or from date
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum          | diff         |
       | '1984-10-28' | '1984-09-25' |
   ✔  And no side effects
  Scenario Outline: [1] Should add or subtract duration to or from date
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | sum          | diff         |
       | '1997-10-11' | '1971-10-12' |
      Step failed:
      Defined: tests/tck/features/expressions/temporal/Temporal8.feature:45:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["sum", "diff"], values: {"sum": Date(DateValue { date: 1997-10-10 }), "diff": Date(DateValue { date: 1971-10-13 })} }
  Scenario Outline: [2] Should add or subtract duration to or from local time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                  | diff                 |
       | '04:44:24.000000003' | '20:18:03.999999999' |
   ✔  And no side effects
  Scenario Outline: [2] Should add or subtract duration to or from local time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                  | diff                 |
       | '04:20:24.000000001' | '20:42:04.000000001' |
   ✔  And no side effects
  Scenario Outline: [2] Should add or subtract duration to or from local time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                  | diff                 |
       | '22:29:27.500000004' | '02:33:00.499999998' |
   ✔  And no side effects
  Scenario Outline: [3] Should add or subtract duration to or from time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                        | diff                       |
       | '04:44:24.000000003+01:00' | '20:18:03.999999999+01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should add or subtract duration to or from time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                        | diff                       |
       | '04:20:24.000000001+01:00' | '20:42:04.000000001+01:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should add or subtract duration to or from time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                        | diff                       |
       | '22:29:27.500000004+01:00' | '02:33:00.499999998+01:00' |
   ✔  And no side effects
  Scenario Outline: [4] Should add or subtract duration to or from local date time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                             | diff                            |
       | '1997-03-26T04:44:24.000000003' | '1972-04-26T20:18:03.999999999' |
   ✔  And no side effects
  Scenario Outline: [4] Should add or subtract duration to or from local date time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                             | diff                            |
       | '1984-10-29T04:20:24.000000001' | '1984-09-24T20:42:04.000000001' |
   ✔  And no side effects
  Scenario Outline: [4] Should add or subtract duration to or from local date time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                             | diff                            |
       | '1997-10-11T22:29:27.500000004' | '1971-10-12T02:33:00.499999998' |
   ✔  And no side effects
  Scenario Outline: [5] Should add or subtract duration to or from date time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                                   | diff                                  |
       | '1997-03-26T04:44:24.000000003+01:00' | '1972-04-26T20:18:03.999999999+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should add or subtract duration to or from date time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                                   | diff                                  |
       | '1984-10-29T04:20:24.000000001+01:00' | '1984-09-24T20:42:04.000000001+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should add or subtract duration to or from date time
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                                   | diff                                  |
       | '1997-10-11T22:29:27.500000004+01:00' | '1971-10-12T02:33:00.499999998+01:00' |
   ✔  And no side effects
  Scenario Outline: [6] Should add or subtract durations
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                              | diff   |
       | 'P24Y10M28DT32H26M20.000000002S' | 'PT0S' |
   ✔  And no side effects
  Scenario Outline: [6] Should add or subtract durations
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                         | diff                        |
       | 'P12Y6MT32H2M20.000000001S' | 'P12Y4M28DT24M0.000000001S' |
   ✔  And no side effects
  Scenario Outline: [6] Should add or subtract durations
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                             | diff                             |
       | 'P25Y4M43DT50H11M23.500000004S' | 'P-6M-15DT-17H-45M-3.500000002S' |
   ✔  And no side effects
  Scenario Outline: [6] Should add or subtract durations
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                         | diff                             |
       | 'P12Y6MT32H2M20.000000001S' | 'P-12Y-4M-28DT-24M-0.000000001S' |
   ✔  And no side effects
  Scenario Outline: [6] Should add or subtract durations
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                 | diff   |
       | 'P2M-28DT31H38M20S' | 'PT0S' |
   ✔  And no side effects
  Scenario Outline: [6] Should add or subtract durations
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                           | diff                                 |
       | 'P13Y15DT49H47M23.500000003S' | 'P-12Y-10M-43DT-18H-9M-3.500000003S' |
   ✔  And no side effects
  Scenario Outline: [6] Should add or subtract durations
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                             | diff                        |
       | 'P25Y4M43DT50H11M23.500000004S' | 'P6M15DT17H45M3.500000002S' |
   ✔  And no side effects
  Scenario Outline: [6] Should add or subtract durations
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                           | diff                           |
       | 'P13Y15DT49H47M23.500000003S' | 'P12Y10M43DT18H9M3.500000003S' |
   ✔  And no side effects
  Scenario Outline: [6] Should add or subtract durations
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | sum                              | diff   |
       | 'P25Y10M58DT67H56M27.000000006S' | 'PT0S' |
   ✔  And no side effects
  Scenario Outline: [7] Should multiply or divide durations by numbers
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | prod                            | div                             |
       | 'P12Y5M14DT16H13M10.000000001S' | 'P12Y5M14DT16H13M10.000000001S' |
   ✔  And no side effects
  Scenario Outline: [7] Should multiply or divide durations by numbers
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | prod                             | div                 |
       | 'P24Y10M28DT32H26M20.000000002S' | 'P6Y2M22DT13H21M8S' |
      Step failed:
      Defined: tests/tck/features/expressions/temporal/Temporal8.feature:188:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["prod", "div"], values: {"prod": Duration(DurationValue { months: 298, days: 28, seconds: 116780, nanos: 2 }), "div": Duration(DurationValue { months: 74, days: 22, seconds: 48068, nanos: 1 })} }
  Scenario Outline: [7] Should multiply or divide durations by numbers
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | prod                | div                              |
       | 'P6Y2M22DT13H21M8S' | 'P24Y10M28DT32H26M20.000000002S' |
      Step failed:
      Defined: tests/tck/features/expressions/temporal/Temporal8.feature:188:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["prod", "div"], values: {"prod": Duration(DurationValue { months: 74, days: 22, seconds: 48068, nanos: 1 }), "div": Duration(DurationValue { months: 298, days: 28, seconds: 116780, nanos: 2 })} }
Feature: Temporal9 - Truncate Temporal Values
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2000-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2000-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2000-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2000-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2000-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '2000-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1900-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1900-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1900-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1900-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1900-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1900-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1980-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1980-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1980-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1980-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1980-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1980-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-05' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-01-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1983-01-05' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1983-01-03' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1983-01-05' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1983-01-03' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-02' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-01' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-09' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-08' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-09' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-08' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-09' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-08' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-11' |
   ✔  And no side effects
  Scenario Outline: [1] Should truncate date
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result       |
       | '1984-10-11' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '2000-01-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '2000-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '2000-01-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '2000-01-02T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '2000-01-01T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '2000-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '2000-01-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '2000-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '2000-01-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1900-01-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1900-01-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '2000-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1900-01-02T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1900-01-01T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '2000-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1900-01-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1900-01-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '2000-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1980-01-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1980-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1980-01-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1980-01-02T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1980-01-01T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1980-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1980-01-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1980-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1980-01-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-01-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-01-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-01-02T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-01-01T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-01-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-01-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-01-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-01-05T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-01-02T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-01-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1983-01-05T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1983-01-03T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1983-01-03T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1983-01-05T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1983-01-03T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1983-01-03T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-02T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-01T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-02T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-01T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-02T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-01T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-01T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-09T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-08T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-08T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-09T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-08T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-08T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-09T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-08T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-08T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T00:00:00.000000002Z' |
      Step failed:
      Defined: tests/tck/features/expressions/temporal/Temporal9.feature:104:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["result"], values: {"result": DateTime(DateTimeValue { datetime: 1984-10-11T00:00:00+00:00, timezone_name: None })} }
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-11T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-10-11T00:00:00.000000002+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-11T00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✘  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T00:00:00.000000002Z' |
      Step failed:
      Defined: tests/tck/features/expressions/temporal/Temporal9.feature:104:5
      Matched: tests/tck/main.rs:268:1
      Step panicked. Captured output: Row 0 has no matching expected row: Record { columns: ["result"], values: {"result": DateTime(DateTimeValue { datetime: 1984-10-11T00:00:00+00:00, timezone_name: None })} }
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T00:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-11T00:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-10-11T12:00:00.000000002-01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-11T12:00-01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:00:00.000000002Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:00+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-11T12:00Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-10-11T12:31:00.000000002-01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:31+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                   |
       | '1984-10-11T12:31-01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:31:00.000000002Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                     |
       | '1984-10-11T12:31+01:00[Europe/Stockholm]' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result              |
       | '1984-10-11T12:31Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-10-11T12:31:14.000000002+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                      |
       | '1984-10-11T12:31:14+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:31:14.000000002Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                 |
       | '1984-10-11T12:31:14Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-10-11T12:31:14.645000002+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:31:14.645000002Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '1984-10-11T12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                                |
       | '1984-10-11T12:31:14.645876002+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                             |
       | '1984-10-11T12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                           |
       | '1984-10-11T12:31:14.645876002Z' |
   ✔  And no side effects
  Scenario Outline: [2] Should truncate datetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                        |
       | '1984-10-11T12:31:14.645876Z' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '2000-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '2000-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '2000-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '2000-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '2000-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '2000-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1900-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1900-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1900-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1900-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1900-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1900-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1980-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1980-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1980-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1980-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1980-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1980-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-01-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-01-05T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-01-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1983-01-05T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1983-01-03T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1983-01-05T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1983-01-03T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-02T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-01T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-09T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-08T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-09T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-08T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-09T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-08T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T00:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T00:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T00:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T00:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:00' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:31' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '1984-10-11T12:31' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.000000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-11T12:31:14' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.000000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '1984-10-11T12:31:14' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-10-11T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645000002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                    |
       | '1984-10-11T12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645876002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-10-11T12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                          |
       | '1984-10-11T12:31:14.645876002' |
   ✔  And no side effects
  Scenario Outline: [3] Should truncate localdatetime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                       |
       | '1984-10-11T12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '00:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '00:00' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '00:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '00:00' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:00' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:00' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:00' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:00:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:00' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:31' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:31' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:31' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:00.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result  |
       | '12:31' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result     |
       | '12:31:14' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result     |
       | '12:31:14' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result     |
       | '12:31:14' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.000000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result     |
       | '12:31:14' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result         |
       | '12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result         |
       | '12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result         |
       | '12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645000002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result         |
       | '12:31:14.645' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645876002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result            |
       | '12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645876002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result            |
       | '12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645876002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result            |
       | '12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645876002' |
   ✔  And no side effects
  Scenario Outline: [4] Should truncate localtime
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result            |
       | '12:31:14.645876' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '00:00:00.000000002+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '00:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '00:00:00.000000002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | '00:00Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:00:00.000000002-01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:00-01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:00:00.000000002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | '12:00Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:00:00.000000002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | '12:00Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:00:00.000000002-01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:00+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:00-01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:00.000000002-01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:31-01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:00.000000002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | '12:31Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:00.000000002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | '12:31Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:00.000000002-01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result        |
       | '12:31-01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:14.000000002+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | '12:31:14+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.000000002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result      |
       | '12:31:14Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.000000002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result      |
       | '12:31:14Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:14.000000002+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result           |
       | '12:31:14+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:14.645000002+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.645000002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result          |
       | '12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.645000002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result          |
       | '12:31:14.645Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:14.645000002+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result               |
       | '12:31:14.645+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:14.645876002+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                  |
       | '12:31:14.645876+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.645876002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '12:31:14.645876Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                |
       | '12:31:14.645876002Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result             |
       | '12:31:14.645876Z' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                     |
       | '12:31:14.645876002+01:00' |
   ✔  And no side effects
  Scenario Outline: [5] Should truncate time
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result                  |
       | '12:31:14.645876+01:00' |
   ✔  And no side effects
Feature: TypeConversion1 - To Boolean
  Scenario: [1] `toBoolean()` on booleans
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b     |
       | true  |
       | false |
   ✔  And no side effects
  Scenario: [2] `toBoolean()` on valid literal string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b    |
       | true |
   ✔  And no side effects
  Scenario: [3] `toBoolean()` on variables with valid string values
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b     |
       | true  |
       | false |
   ✔  And no side effects
  Scenario: [4] `toBoolean()` on invalid strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | b    |
       | null |
       | null |
       | null |
       | null |
   ✔  And no side effects
  Scenario Outline: [5] Fail `toBoolean()` on invalid types #Example: list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion1.feature:96:5
  Scenario Outline: [5] Fail `toBoolean()` on invalid types #Example: map
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion1.feature:96:5
  Scenario Outline: [5] Fail `toBoolean()` on invalid types #Example: float
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion1.feature:96:5
  Scenario Outline: [5] Fail `toBoolean()` on invalid types #Example: node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion1.feature:96:5
  Scenario Outline: [5] Fail `toBoolean()` on invalid types #Example: relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion1.feature:96:5
  Scenario Outline: [5] Fail `toBoolean()` on invalid types #Example: path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion1.feature:96:5
Feature: TypeConversion2 - To Integer
  Scenario: [1] `toInteger()` on float
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | toInteger(weight) |
       | 82                |
   ✔  And no side effects
  Scenario: [2] `toInteger()` returning null on non-numerical string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | foo  | empty |
       | null | null  |
   ✔  And no side effects
  Scenario: [3] `toInteger()` handling mixed number types
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | int_numbers |
       | [2, 2]      |
   ✔  And no side effects
  Scenario: [4] `toInteger()` handling Any type
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | int_numbers |
       | [2, 2, 1]   |
   ✔  And no side effects
  Scenario: [5] `toInteger()` on a list of strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | int_numbers  |
       | [2, 2, null] |
   ✔  And no side effects
  Scenario: [6] `toInteger()` on a complex-typed expression
   ✔  Given any graph
   ✔  And parameters are:
       | param | 1 |
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result |
       | 0      |
   ✔  And no side effects
  Scenario: [7] `toInteger()` on node property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | name |
       | 42   |
   ✔  And no side effects
  Scenario Outline: [8] Fail `toInteger()` on invalid types #Example: list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion2.feature:135:5
  Scenario Outline: [8] Fail `toInteger()` on invalid types #Example: map
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion2.feature:135:5
  Scenario Outline: [8] Fail `toInteger()` on invalid types #Example: node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion2.feature:135:5
  Scenario Outline: [8] Fail `toInteger()` on invalid types #Example: relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion2.feature:135:5
  Scenario Outline: [8] Fail `toInteger()` on invalid types #Example: path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion2.feature:135:5
Feature: TypeConversion3 - To Float
  Scenario: [1] `toFloat()` on mixed number types
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | float_numbers |
       | [3.4, 3.0]    |
   ✔  And no side effects
  Scenario: [2] `toFloat()` returning null on non-numerical string
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | foo  | empty |
       | null | null  |
   ✔  And no side effects
  Scenario: [3] `toFloat()` handling Any type
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | float_numbers   |
       | [3.4, 3.0, 5.0] |
   ✔  And no side effects
  Scenario: [4] `toFloat()` on a list of strings
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | float_numbers    |
       | [1.0, 2.0, null] |
   ✔  And no side effects
  Scenario: [5] `toFloat()` on node property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | float |
       | 4.0   |
   ✔  And no side effects
  Scenario Outline: [6] Fail `toFloat()` on invalid types #Example: boolean
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion3.feature:110:5
  Scenario Outline: [6] Fail `toFloat()` on invalid types #Example: list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion3.feature:110:5
  Scenario Outline: [6] Fail `toFloat()` on invalid types #Example: map
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion3.feature:110:5
  Scenario Outline: [6] Fail `toFloat()` on invalid types #Example: node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion3.feature:110:5
  Scenario Outline: [6] Fail `toFloat()` on invalid types #Example: relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion3.feature:110:5
  Scenario Outline: [6] Fail `toFloat()` on invalid types #Example: path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion3.feature:110:5
Feature: TypeConversion4 - To String
  Scenario: [1] `toString()` handling integer literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | bool |
       | '42' |
   ✔  And no side effects
  Scenario: [2] `toString()` handling boolean literal
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | bool   |
       | 'true' |
   ✔  And no side effects
  Scenario: [3] `toString()` handling inlined boolean
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | bool    |
       | 'false' |
   ✔  And no side effects
  Scenario: [4] `toString()` handling boolean properties
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | toString(m.watched) |
       | 'true'              |
   ✔  And no side effects
  Scenario: [5] `toString()` should work on Any type
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | list                        |
       | ['1', '2.3', 'true', 'apa'] |
   ✔  And no side effects
  Scenario: [6] `toString()` on a list of integers
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | string_numbers  |
       | ['1', '2', '3'] |
   ✔  And no side effects
  Scenario: [7] `toString()` on node property
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | toString(n.rating) |
       | '4'                |
   ✔  And no side effects
  Scenario: [8] `toString()` should accept potentially correct types 1
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | 'male'   |
       | 'female' |
       | 'x'      |
   ✔  And no side effects
  Scenario: [9] `toString()` should accept potentially correct types 2
   ✔  Given any graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | result   |
       | 'male'   |
       | 'female' |
       | 'x'      |
   ✔  And no side effects
  Scenario Outline: [10] Fail `toString()` on invalid types #Example: list
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion4.feature:162:5
  Scenario Outline: [10] Fail `toString()` on invalid types #Example: map
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion4.feature:162:5
  Scenario Outline: [10] Fail `toString()` on invalid types #Example: node
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion4.feature:162:5
  Scenario Outline: [10] Fail `toString()` on invalid types #Example: relationship
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion4.feature:162:5
  Scenario Outline: [10] Fail `toString()` on invalid types #Example: path
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ?  Then a TypeError should be raised at runtime: InvalidArgumentValue
      Step skipped: tests/tck/features/expressions/typeConversion/TypeConversion4.feature:162:5
Feature: CountingSubgraphMatches1 - Matching subgraph patterns and count the number of matches
  Scenario: [1] Undirected match in self-relationship graph, count
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And no side effects
  Scenario: [2] Undirected match of self-relationship in self-relationship graph, count
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And no side effects
  Scenario: [3] Undirected match on simple relationship graph, count
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 2        |
   ✔  And no side effects
  Scenario: [4] Directed match on self-relationship graph, count
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And no side effects
  Scenario: [5] Directed match of self-relationship on self-relationship graph, count
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And no side effects
  Scenario: [6] Counting undirected self-relationships in self-relationship graph
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And no side effects
  Scenario: [7] Counting distinct undirected self-relationships in self-relationship graph
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(DISTINCT r) |
       | 1                 |
   ✔  And no side effects
  Scenario: [8] Directed match of a simple relationship, count
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 1        |
   ✔  And no side effects
  Scenario: [9] Counting directed self-relationships
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(r) |
       | 1        |
   ✔  And no side effects
  Scenario: [10] Mixing directed and undirected pattern parts with self-relationship, count
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 2        |
   ✔  And no side effects
  Scenario: [11] Mixing directed and undirected pattern parts with self-relationship, undirected count
   ✔  Given an empty graph
   ✔  And having executed:
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | count(*) |
       | 6        |
   ✔  And no side effects
Feature: TriadicSelection1 - Query three related nodes on binary-tree graphs
  Scenario: [1] Handling triadic friend of a friend
   ✔  Given the binary-tree-1 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b2'   |
       | 'b3'   |
       | 'c11'  |
       | 'c12'  |
       | 'c21'  |
       | 'c22'  |
   ✔  And no side effects
  Scenario: [2] Handling triadic friend of a friend that is not a friend
   ✔  Given the binary-tree-1 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b3'   |
       | 'c11'  |
       | 'c12'  |
       | 'c21'  |
       | 'c22'  |
   ✔  And no side effects
  Scenario: [3] Handling triadic friend of a friend that is not a friend with different relationship type
   ✔  Given the binary-tree-1 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b2'   |
       | 'c11'  |
       | 'c12'  |
       | 'c21'  |
       | 'c22'  |
   ✔  And no side effects
  Scenario: [4] Handling triadic friend of a friend that is not a friend with superset of relationship type
   ✔  Given the binary-tree-1 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'c11'  |
       | 'c12'  |
       | 'c21'  |
       | 'c22'  |
   ✔  And no side effects
  Scenario: [5] Handling triadic friend of a friend that is not a friend with implicit subset of relationship type
   ✔  Given the binary-tree-1 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b3'   |
       | 'b4'   |
       | 'c11'  |
       | 'c12'  |
       | 'c21'  |
       | 'c22'  |
       | 'c31'  |
       | 'c32'  |
       | 'c41'  |
       | 'c42'  |
   ✔  And no side effects
  Scenario: [6] Handling triadic friend of a friend that is not a friend with explicit subset of relationship type
   ✔  Given the binary-tree-1 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b3'   |
       | 'b4'   |
       | 'c11'  |
       | 'c12'  |
       | 'c21'  |
       | 'c22'  |
       | 'c31'  |
       | 'c32'  |
       | 'c41'  |
       | 'c42'  |
   ✔  And no side effects
  Scenario: [7] Handling triadic friend of a friend that is not a friend with same labels
   ✔  Given the binary-tree-2 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b3'   |
       | 'c11'  |
       | 'c21'  |
   ✔  And no side effects
  Scenario: [8] Handling triadic friend of a friend that is not a friend with different labels
   ✔  Given the binary-tree-2 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'c12'  |
       | 'c22'  |
   ✔  And no side effects
  Scenario: [9] Handling triadic friend of a friend that is not a friend with implicit subset of labels
   ✔  Given the binary-tree-2 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b3'   |
       | 'c11'  |
       | 'c21'  |
   ✔  And no side effects
  Scenario: [10] Handling triadic friend of a friend that is not a friend with implicit superset of labels
   ✔  Given the binary-tree-2 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b3'   |
       | 'c11'  |
       | 'c12'  |
       | 'c21'  |
       | 'c22'  |
   ✔  And no side effects
  Scenario: [11] Handling triadic friend of a friend that is a friend
   ✔  Given the binary-tree-2 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b2'   |
   ✔  And no side effects
  Scenario: [12] Handling triadic friend of a friend that is a friend with different relationship type
   ✔  Given the binary-tree-1 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b3'   |
   ✔  And no side effects
  Scenario: [13] Handling triadic friend of a friend that is a friend with superset of relationship type
   ✔  Given the binary-tree-1 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b2'   |
       | 'b3'   |
   ✔  And no side effects
  Scenario: [14] Handling triadic friend of a friend that is a friend with implicit subset of relationship type
   ✔  Given the binary-tree-1 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b1'   |
       | 'b2'   |
   ✔  And no side effects
  Scenario: [15] Handling triadic friend of a friend that is a friend with explicit subset of relationship type
   ✔  Given the binary-tree-1 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b1'   |
       | 'b2'   |
   ✔  And no side effects
  Scenario: [16] Handling triadic friend of a friend that is a friend with same labels
   ✔  Given the binary-tree-2 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b2'   |
   ✔  And no side effects
  Scenario: [17] Handling triadic friend of a friend that is a friend with different labels
   ✔  Given the binary-tree-2 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
   ✔  And no side effects
  Scenario: [18] Handling triadic friend of a friend that is a friend with implicit subset of labels
   ✔  Given the binary-tree-2 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b2'   |
   ✔  And no side effects
  Scenario: [19] Handling triadic friend of a friend that is a friend with implicit superset of labels
   ✔  Given the binary-tree-2 graph
   ✔  When executing query:
   ✔  Then the result should be, in any order:
       | c.name |
       | 'b2'   |
   ✔  And no side effects
[Summary]
192 features
3897 scenarios (3728 passed, 137 skipped, 32 failed)
15789 steps (15620 passed, 137 skipped, 32 failed)
