After today's daily we discussed this PR and we found a good example why the current approach is not good:

CREATE (n {prop: [1,2]});
MATCH (n) FOREACH ( i IN n.prop | CREATE (:V { i: i})) RETURN n;

the second query should return one row, but for us it returns two. That is the main reason we should somehow embed another plane inside FOREACH instead of making one, "linear" plan.

Maybe we don't need the embed a plan, we can build one plan, but the FOREACH should have an additional side branch which contains all the inside clauses. Let's call them main and side. When the FOREACH is pulled, it should pull main once, populate the frame with everything that is necessary for side, and then it should exhaust side and "pass through" the original row from main. I don't see the exact implementation, but I think this is doable.

Tomorrow we will discuss this in more details.

Another query that doesn't behave correctly in my opinion: MATCH (n) FOREACH ( li IN n.prop | CREATE (:F4 {prop: li}) CREATE (m:F5 {prop2: li}) SET n.li = li) RETURN m;

It should fail because m shouldn't be defined in RETURN, but it succeeds:

memgraph> MATCH (n) DETACH DELETE n;
Empty set (0.001 sec)
memgraph> CREATE (n {prop: [1,2]});
Empty set (0.001 sec)
memgraph> MATCH (n) FOREACH ( li IN n.prop | CREATE (:F4 {prop: li}) CREATE (m:F5 {prop2: li}) SET n.li = li) RETURN m;
+------------------+
| m                |
+------------------+
| (:F5 {prop2: 1}) |
| (:F5 {prop2: 2}) |
+------------------+
2 rows in set (0.001 sec)

docs PR memgraph/docs#355