How to find all incoming edges via a relation to a target Vertex without restricting the type of the source Vertex?

[torchss]

In aGRAPH, I would like to discover all the objects that have an edge rel to Vertex of type ObjT2

FROM GRAPH_TABLE (aGRAPH
  MATCH (a:*)-[k:rel]->(b:ObjT2)
  COLUMNS (a.id, b.id)
)

In aGRAPH, object a can be one of 10 different types, all of which are exposed as a Vertex in aGRAPH.

The query, as is, throws:

Parser Error:
syntax error at or near "*"

LINE 2:       MATCH (a:*)-[k:rel]->(b:ObjT2)

Should I have written the query differently (short of explicitly enumerating all the 10 different types)?

[Dtenwolde]

Hi @torchss
Currently DuckPGQ doesn't support multi-label style queries like the one you mention. I have anonymous vertex and edge patterns planned (#195), but those will still bind to a single table. Our reasoning behind only allowing vertex and edge patterns to bind to a single table (at least for the foreseeable future) is that we use the internal rowid (this is a dense unique ID per row from 0 to the number of elements in the table) for path-finding style queries. If we were to allow multiple labels, these rowids wouldn't be unique. Apologies about that :)

[torchss]

Thank You for the fast response Daniel, especially when on your holiday!

If I would like to discover all the objects that have an edge rel to Vertex of type ObjT2, are there other ways I can write a query that would output the expected result?

Worst case, I can think of 2 solutions:

1. Write a UDF in Python
2. Go outside aGRAPH and write "regular" SQL queries that operate directly on the underlying vertex tables

However, I like your SQL/PGQ extension very much and it would be rather pleasant to write a SQL/PGQ query using it.

On an slightly related note, this presentation has a query on slide 18:

(o)->(py:Payment WHERE py.type = 'CC')<-()->(o:Order)->(p:Product) COLUMNS (p.name)

The intention is to "Find all products paid by credit card"

Will I be able to run this query using your extension? Also, if I should turn this portion of my question into a separate discussion, let me know

Best Regards,

[hpvd]

just released DuckDB 1.3 now supports using UUIDv7 which combines a Unix timestamp in milliseconds and random bits, offering both uniqueness and sortability.
https://duckdb.org/2025/05/21/announcing-duckdb-130.html#uuid-v7-support
-> couldn’t one think of a procedure to make use of this instead of rowid?

[hpvd]

there is currently a tiny prob with implementation of UUIDv7 in DuckDB which will be fixed in the next version:
duckdb/duckdb#17611

edit: this is fixed

[Dtenwolde]

The nice property of rowid's is that they are a dense representation, from 0 to n and therefore allow us to use arrays internally. Additionally, every table has the rowid as one of the columns, so we don't need to rely on a column provided by users. But perhaps I am missing something in regards to this UUIDv7 :)

[hpvd]

did not put the things together yet, but this may also be of help:
https://duckdb.org/2025/05/23/using-key.html

[torchss]

Fair point. Before duckpgq came along and simplified my life, painful, elaborate Recursive CTEs were my goto when querying graphs in DuckDB. I am just hoping to enjoy duckpgq more

If you're planning to put together something, let me know, I am happy to collaborate and test things out.