While GQL is a graph query language, it uses tables to hold results during query execution. These tables consist of rows of records corresponding to nodes, edges, paths, or values referenced by variables.

Each GQL statement produces a binding table as a container for variable bindings. For example, the MATCH statement generates a binding table which exposes yielded element and path variables as columns. Once constructed and populated, binding tables remain unchanged.

On the other hand, working table is the temporary table that stores intermediate data. The working table evolves as the query proceeds, hence the term current working table. Though not explicitly visible to users, the working table plays a critical role behind the scenes.

The execution context of each statement enables transition of the working table within the query. The execution context takes the current working table as the incoming working table for the statement, and sets the outgoing working table as the join of the incoming working table and the binding table produced by the statement.

The first statement starts with an empty working table. The binding table of the RETURN statement is the final table and is set as the outgoing working table, which is returned to the client.

FOR target IN ["mochaeach", "purplechalk", "Brainy"]
MATCH (c:Club)
MATCH (u)-[e:Joins]->(c) WHERE u.name = target
FILTER e.memberNo = 1
RETURN target AS User, c._id AS Club