Re: SQL Property Graph Queries (SQL/PGQ)

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Ajay Pal <ajay(dot)pal(dot)k(at)gmail(dot)com>, Imran Zaheer <imran(dot)zhir(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL Property Graph Queries (SQL/PGQ)
Date: 2025-12-09 10:21:16
Message-ID: CAExHW5stjrQwS1gXagy_5xmkAvKg_8QHwV=31vLD1O40y-mQiw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 8, 2025 at 9:24 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 02.12.25 11:00, Ashutosh Bapat wrote:
> >> When you create future patches, consider using the git format-patch -v
> >> option.
> >>
> > I am still using timestamp as a version but passing it to -v instead
> > of treating it as a suffix. I like datestamp as versionstamp for the
> > reasons mentioned upthread.
>
> Date stamps are great, but why is there a hyphen between the "v" and the
> number?

I was using -v=<version number> instead of -v <version number>. Fixed.

>
> I have committed the parse.pl patch, mainly to test it out so that we
> don't have surprises later. (I had problems in the past making it work
> with older Perl versions, but things seems to have shifted forward now.)
> It can live on its own, I think.

+1. Buildfarm seems to be happy with the change.

>
> 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.

We do not support full edge undirected. gram.y doesn't have grammar
for the same. In fact, I don't think we have a way to specify
undirected edges in the property graph DDL itself. Do you think we
should implement ~[ ] ~?

> Also, make sure the role names in graph_table_rls.sql start with regress_:
>
> CREATE USER graph_rls_alice NOLOGIN;
> +WARNING: roles created by regression test cases should have names
> starting with "regress_"
>
> (This is the FreeBSD CI failure.)
>

Thanks for pointing that out. I can reproduce the failure on my
laptop. Fixed in the attached patch. I have used regress_graph_rls_ as
a user or role name prefix. It's a bit long but I see other tests also
using longer names regress_file_fdw_superuser. If we want a shorter
name we could use regress_pg_rls (pg: for property graph) but that can
be easily confused with PostgreSQL.

[1] https://www.postgresql.org/message-id/CAExHW5vqo7iTcVznspb3HHD87Ps3Q%3DJF6_gg%2Bh5mhyuwhd3Q4Q%40mail.gmail.com

--
Best Wishes,
Ashutosh Bapat

Attachment Content-Type Size
v20251209-0001-WIP-SQL-Property-Graph-Queries-SQL-PGQ.patch text/x-patch 660.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message VASUKI M 2025-12-09 10:23:23 Re: BUG #19095: Test if function exit() is used fail when linked static
Previous Message Julien Rouhaud 2025-12-09 09:55:16 Re: citext_1.out, citext.out confusing comment