On Sun, Dec 14, 2025 at 1:28 AM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 09.12.25 11:21, Ashutosh Bapat wrote:
> >> It looks like undirected matching -[ ]- (without arrows) doesn't work
> >> correctly. It seems to just match in one direction. I don't see any
> >> tests. Is this implemented?
> >>
> > -[]- is called full edge any direction
> > <full edge any direction> ::=
> > <minus left bracket> <element pattern filler> <right bracket minus>
> >
> > ~[]~ is defined as full edge undirected
> > <full edge undirected> ::=
> > <tilde left bracket> <element pattern filler> <right bracket tilde>
> >
> > The patch supports full edge any direction since [1] in response to
> > Ajay Pal's report. Such a pattern matches edges in both the
> > directions. There's also a test
> > -- edges directed in both ways - to and from v2
> > SELECT * FROM GRAPH_TABLE (g1 MATCH (v1 IS vl2)-[conn]-(v2) COLUMNS
> > (v1.vname AS v1name, conn.ename AS cname, v2.vname AS v2name));
> > v1name | cname | v2name
> > --------+-------+--------
> > v21 | e122 | v12
> > v22 | e121 | v11
> > v22 | e231 | v32
> > (3 rows)
> >
> > SELECT * FROM GRAPH_TABLE (g1 MATCH (v1 IS vl2)-(v2) COLUMNS (v1.vname
> > AS v1name, v2.vname AS v2name));
> > v1name | v2name
> > --------+--------
> > v21 | v12
> > v22 | v11
> > v22 | v32
> > (3 rows)
> >
> > it's matching edges to and from vertices in v2. For example e121 is an
> > edge from v11 to v22 whereas e231 is an edge from v22 to v32.
>
> Attached is a test case from an Oracle web site (the URL is in the
> file). At the end there are three queries, one left, one right, one any
> direction. The latter should result in the union of the first two, but
> it doesn't.
Thanks for the example. I see it now. The code, in previous patch,
works when the vertices adjacent to an edge come from different
tables. In such a case only right or left direction is possible. When
the adjacent vertices of an edge come from the same table edge can be
from left or right and we need to match both the directions. The edge
link quals should have conditions for edges in both directions
connected by OR. Done that way in the attached patch. Also added a few
more queries containing edges in any direction.
I also noticed the following mistakes in the patch and fixed those.
1. e3_3 entry for property graph g1 in graph_table.sql was using the
same column as both source and destination key. Fixed that to use
appropriate columns.
2. When GRAPH_TABLE has no conditions whatsoever, e.g. GRAPH_TABLE (g1
MATCH () COLUMNS (1)), generate_query_for_graph_path() constructed a
bool expression representing NIL quals. This does not cause a problem
since somewhere down the line, a bool expression without any clause is
appropriately replaced with true or false. However, it crashed when
passed through pg_get_querydef() since get_rule_expr() calls linitial
on expr->args without checking for NIL-ness. Fixed the construction of
bool expression in generate_query_for_graph_path().
rewriteGraphTable() has following code
#if 0
elog(INFO, "rewritten:\n%s", pg_get_querydef(copyObject(parsetree), false));
#endif
Do we want to remove it or keep it with some note or under #ifdef
DEBUG_GRAPH_TABLE_REWRITE or some such? I am mildly leaning towards
keeping it under the #ifdef, but not a whole lot. Anybody who wants to
debug can add that single line, if they want.
I have added the fixes as a separate 0002 patch. Once reviewed I will
squash it into 0001 in the next round.
Rebased patches on the latest HEAD which required me to move
graph_table.sql to another parallel group.
--
Best Wishes,
Ashutosh Bapat
