| 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.
--
Best Wishes,
Ashutosh Bapat
| 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 |