Re: SQL Property Graph Queries (SQL/PGQ)

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, zengman <zengman(at)halodbtech(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SQL Property Graph Queries (SQL/PGQ)
Date: 2026-03-25 08:24:12
Message-ID: 70bdbc98-a9c6-427f-bf87-6c1bbc72a352@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16.03.26 17:28, Ashutosh Bapat wrote:
> On Mon, Mar 16, 2026 at 8:39 PM zengman <zengman(at)halodbtech(dot)com> wrote:
>>
>> Hi,
>>
>> The commit 2f094e7ac691abc9d2fe0f4dcf0feac4a6ce1d9c delivers an excellent feature, and the file `rewriteGraphTable.c` was introduced as part of this commit.
>> I've noticed that this code file could benefit from some tidying up, so please review the diff file attached below.
>> This diff only includes **basic cleanup** of `rewriteGraphTable.c` – it’s just a simple pass,
>> and there may be other minor omissions that haven’t been addressed yet.
>
> Hi Man,
> Thanks for the patch. I reviewed the cleanup you propose. Most of the
> changes look good to me, except the changes related to pstate. We have
> both patterns in the code, one which uses free_parsestate() explicitly
> and another that doesn't. In this case, we don't set
> p_target_relation, and we don't touch p_next_resno. So the only thing
> that free_parsestate() does it to free pstate, which will taken care
> of by the memory context management. So not needed. Any other reason
> you want to call free_parsestate() explicitly?
>
> Attached patch has changes other that pstate related changes.

committed this

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-03-25 08:25:05 Re: [Proposal] Adding Log File Capability to pg_createsubscriber
Previous Message Amit Kapila 2026-03-25 08:21:14 Re: [Patch] add new parameter to pg_replication_origin_session_setup