On 26.03.26 08:08, Ashutosh Bapat wrote:
> Consider following query
> Query1
> SELECT x1.a, g.* FROM x1, GRAPH_TABLE (myshop MATCH (x1 IS
> customers)-[IS customer_orders]->(o IS orders WHERE o.order_id = x1.a)
> COLUMNS (x1.name AS customer_name, x1.customer_id AS cid)) g;
>
> x1 is a table referenced in from clause as well as an element pattern
> variable in path pattern. If we don't allow backward (cross)
> referencing, x1.a in the element pattern o resolves to the table x1's
> column a, but x1.name resolves to element x1's property reference
> name. So within the same graph pattern x1 may get resolved to two
> different things, even though x1 was declared before using it. Is that
> how we expect it to happen? Let's call this inconsistency1.
I don't think this interpretation is correct.
Even if we don't support non-local element variable references, we still
need to *recognize* them. We just don't need to be able to process
them, we can error out if we see them.
> 0001: is a small adjustment to make sure that we add an element
> variable name to the graph table namespace only once. This isn't a
> problem right now, but we will have to do that anyway in [1] and it
> has some effect one 0002.
committed
> 0002: prohibits cross element variable references within graph_table
> clause. It adds a new member GraphTableParseState::cur_variable to
> track the variable name of the current pattern being transformed. We
> can not use llast() simply because a. pattern currently being
> transformed may not have name, so llast will be misleading b. changes
> in 0001. We may want to combine 0001 and 0002 when committing.
(under discussion)
> 0003: prohibits consecutive element patterns of the same kind
committed (I made the error message wording a bit more compact.)
> 0004: some cleanup remaining from
> 5282bf535e474dc2517f2e835d147420ae2144de. We may want to wait to
> accumulate more cleanups.
I don't think this patch goes into the right direction. The existing
code seems preferable.
