Re: SQL/PGQ: All properties reference

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: assam258(at)gmail(dot)com
Cc: Junwang Zhao <zhjwpku(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL/PGQ: All properties reference
Date: 2026-04-03 05:37:03
Message-ID: CAExHW5s9aFkBDXuqf9np2asSRxm7vfuQAEbrXeHLOLCmwNjW4g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 3, 2026 at 7:24 AM Henson Choi <assam258(at)gmail(dot)com> wrote:
>
> Hi Ashutosh,
>
>> I am starting a new thread to discuss all properties reference feature
>> which was not committed with the main patch. [1]
>>
>> A <variable>.* is called all properties reference and it is allowed
>> only in COLUMNs clause. Interpreting subclause 9.2 and 9.3 together,
>> it expands to a list of graph property references <variable>.p1, ...
>> <variable>.pn where p1, ..., pn are the properties of the labels which
>> satisfy the label expression in the element pattern identified by
>> <variable>. The graph property references are added to the COLUMNs
>> clause in place of the all property reference, just like how <table>.*
>> expands in SELECT's targetlist.
>>
>> In the current implementation, we delay resolving graph property
>> references (<variable>.<property>) till the time query is generated
>> (generate_query_for_graph_path()). If we delay the all properties
>> reference till that time, we can not determine the data types and
>> names of the columns in the COLUMNs list. So we need to do that when
>> the COLUMNs clause is resolved. This means that the properties
>> associated with the labels needs to be resolved earlier. Since the
>> properties are not associated with labels directly but through the
>> elements, we need to find at least one element for every label in the
>> label expression. In brief, all the namespace resolution need to
>> happen before we transform COLUMNs clause. The patch rearranges the
>> code that way.
>
>
> I tried applying v20260318 on top of master to review it, but ran
> into merge conflicts in two files:
>
> - parse_graphtable.c
> - rewriteGraphTable.c
>
> The conflicts come from this commit that was added after the main PGQ
> commit (2f094e7ac69):
>
> - a0dd0702e46 Fix cross variable references in graph pattern causing
> segfault
>
> Would it be possible to rebase the patch on the current master so
> I can review it cleanly?

I want to focus on resizable shared memory structures for PG 19 [1] in
whatever time remains until the feature freeze. If Peter feels that we
should get this in PG 19, I will rebase and finish the patch. I am ok,
if somebody else wants to rebase and finish this for PG 19 as well.
Sorry if this patch slips PG 19, but I will pick it up for PG 20, once
the branch opens.

[1] https://www.postgresql.org/message-id/CAExHW5vM1bneLYfg0wGeAa=52UiJ3z4vKd3AJ72X8Fw6k3KKrg@mail.gmail.com

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2026-04-03 05:52:45 Re: Eliminating SPI / SQL from some RI triggers - take 3
Previous Message Peter Geoghegan 2026-04-03 05:17:14 Re: index prefetching