Could not find rte error when using path variable in WHERE

[MuhammadTahaNaveed]

Describe the bug
Could not find rte error when using path variable in WHERE

How are you accessing AGE (Command line, driver, etc.)?

• terminal

What data setup do we need to do?

SELECT * FROM cypher('graph',$$
    CREATE (n)-[:KNOWS {n:'hello'}]->({n:'hello'})
$$) as (a agtype);

What is the command that caused the error?

SELECT * FROM cypher('graph', $$
    MATCH p = (m)-[]->(b) 
    WHERE length(p) >1
    RETURN p
$$) AS (pattern agtype);

ERROR:  could not find rte for p
LINE 3:     WHERE length(p) >1 return p
                         ^

Expected behavior
Expected it to work without error.

Environment (please complete the following information):

• latest (PG13 master)

[MatheusFarias03]

It appears that the error is related to the pnsi in the transform_ColumnRef() function. The pnsi tries to receive a value from refnameNamespaceItem() but it returns nil. In this postgres function, it goes inside a loop and checks if the pstate variable is different than NULL, updating it with pstate = pstate->parentParseState;. It also verifies if the relid is valid with OidIsValid(relId)). Depending on this, it will call different functions to give a value for the result variable. If this variable has a non-nil value, it returns it. But this variable always receives a NULL value throughout the while loop.

	while (pstate != NULL)
	{
		ParseNamespaceItem *result;

		if (OidIsValid(relId))
			result = scanNameSpaceForRelid(pstate, relId, location);
		else
			result = scanNameSpaceForRefname(pstate, refname, location);

		if (result)
			return result;

		if (sublevels_up)
			(*sublevels_up)++;
		else
			break;

		pstate = pstate->parentParseState;
	}
	return NULL;

After that, it goes back to AGE's function and the else error section is executed:

                pnsi = refnameNamespaceItem(pstate, NULL, colname,
                                           cref->location, &levels_up);
                if (pnsi)
                {
                    node = transform_WholeRowRef(pstate, pnsi, cref->location,
                                                 levels_up);
                }
                else
                {
                    ereport(ERROR,
                                (errcode(ERRCODE_UNDEFINED_COLUMN),
                                 errmsg("could not find rte for %s", colname),
                                 parser_errposition(pstate, cref->location)));
                }

The code calls only scanNamespaceItemForRefname(), and calls it three times. The rte->eref->aliasname has value only the first time this function is called, the other two times it contains no value. And these values are: 'm', '_', and 'b'. These characters match the same ones provided in the path (m)-[]->(b), but the 'p' character cannot be found. When it does the comparison of the strings with if (strcmp(rte->eref->aliasname, refname) == 0), it just skips that, not being able to find the correct nsitem and letting result to be nil.

		if (strcmp(rte->eref->aliasname, refname) == 0)
		{
			if (result)
				ereport(ERROR,
						(errcode(ERRCODE_AMBIGUOUS_ALIAS),
						 errmsg("table reference \"%s\" is ambiguous",
								refname),
						 parser_errposition(pstate, location)));
			check_lateral_ref_ok(pstate, nsitem, location);
			result = nsitem;
		}

[jrgemignani]

@MatheusFarias03 @MuhammadTahaNaveed This looks to still be an issue -

psql-15.4-5432-pgsql=# select * from create_graph('graph');
NOTICE:  graph "graph" has been created
 create_graph
--------------

(1 row)

psql-15.4-5432-pgsql=# SELECT * FROM cypher('graph',$$
psql-15.4-5432-pgsql$#     CREATE (n)-[:KNOWS {n:'hello'}]->({n:'hello'})
psql-15.4-5432-pgsql$# $$) as (a agtype);
 a
---
(0 rows)

psql-15.4-5432-pgsql=# SELECT * FROM cypher('graph', $$
psql-15.4-5432-pgsql$#     MATCH p = (m)-[]->(b)
psql-15.4-5432-pgsql$#     WHERE length(p) >1
psql-15.4-5432-pgsql$#     RETURN p
psql-15.4-5432-pgsql$# $$) AS (pattern agtype);
ERROR:  could not find rte for p
LINE 3:     WHERE length(p) >1
                         ^
psql-15.4-5432-pgsql=#

Is there a plan to fix it?

[MuhammadTahaNaveed]

@jrgemignani Thanks for bringing this up.... I'll be working on it.