public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ashutosh Bapat <[email protected]>
To: [email protected]
Cc: Junwang Zhao <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: SQL/PGQ: All properties reference
Date: Fri, 3 Apr 2026 11:07:03 +0530
Message-ID: <CAExHW5s9aFkBDXuqf9np2asSRxm7vfuQAEbrXeHLOLCmwNjW4g@mail.gmail.com> (raw)
In-Reply-To: <CAAAe_zD3==epK=KufoBiLfogztpKbimxc498TUshTOQkkpgOjg@mail.gmail.com>
References: <CAExHW5tYCE9QyCvVraKUeesKW5RTR+mrzsg3u64qSps-RPJR5A@mail.gmail.com>
<CAAAe_zD3==epK=KufoBiLfogztpKbimxc498TUshTOQkkpgOjg@mail.gmail.com>
On Fri, Apr 3, 2026 at 7:24 AM Henson Choi <[email protected]> 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/[email protected]...
--
Best Wishes,
Ashutosh Bapat
view thread (3+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: SQL/PGQ: All properties reference
In-Reply-To: <CAExHW5s9aFkBDXuqf9np2asSRxm7vfuQAEbrXeHLOLCmwNjW4g@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox