Summary

GQL (ISO 39075) uses NEXT to chain linear query stages, passing the working table from one stage to the next. We should explore a similar mechanism for anonymous graph composition — chaining graph constructor stages without requiring named bindings.

Current State

Today, multi-stage graph pipelines require explicit named bindings:

GRAPH g1 = GRAPH { MATCH (a)-[r]->(b) WHERE a.score > 10 }
GRAPH g2 = GRAPH { USE g1 CALL graphistry.degree.write() }
USE g2 MATCH (n) RETURN n.id, n.degree ORDER BY n.degree DESC

Proposed Direction

A NEXT-style operator could enable anonymous chaining:

GRAPH { MATCH (a)-[r]->(b) WHERE a.score > 10 }
NEXT GRAPH { CALL graphistry.degree.write() }
NEXT MATCH (n) RETURN n.id, n.degree ORDER BY n.degree DESC

Each NEXT implicitly passes the current graph to the following stage — no naming needed for linear pipelines. Named bindings (GRAPH g = ...) remain available for DAG-shaped pipelines where a graph is referenced more than once.

Design Considerations

• GQL alignment: GQL's NEXT chains row tables, not graphs. Our extension would chain graph values. Document the semantic difference clearly.
• Mixing row and graph stages: NEXT after a RETURN (row output) vs after a GRAPH { } (graph output) — need clear rules for what the "current value" is at each stage.
• Interaction with USE: NEXT is implicit USE of the previous stage's output. Should explicit USE and NEXT coexist?
• Wire protocol: NEXT could desugar to the existing Chain/Let/Call primitives (like GRAPH { } does today).
• Backward compatibility: NEXT is already a GQL reserved word, so using it aligns with the standard.

References

• GQL NEXT statement: chains linear query stages (ISO/IEC 39075:2024)
• Current GFQL GRAPH { } / USE implementation: feat/cypher-return-graph branch
• G-CORE composability principle: "graphs are the input and output of queries"

🤖 Generated with Claude Code