Re: SQL Property Graph Queries (SQL/PGQ) - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: SQL Property Graph Queries (SQL/PGQ)
Date
Msg-id ac3fa341-4cf6-4365-a511-95c3763b78f7@eisentraut.org
Whole thread Raw
In response to Re: SQL Property Graph Queries (SQL/PGQ)  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
On 18.03.26 16:32, Ashutosh Bapat wrote:
> On Wed, Mar 18, 2026 at 12:59 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>>
>> On 17.03.26 14:57, Peter Eisentraut wrote:
>>> On 16.03.26 16:54, Ashutosh Bapat wrote:
>>>> The patch looks fine to me. While reviewing it, I noticed that the
>>>> function has an extra loop to count the number of variables. I don't
>>>> think it's needed. The count can be obtained from the list length. In
>>>> the attached patch, I have removed that loop. Am I missing something?
>>>>
>>>> 0001 is your patch
>>>> 0002 removes the loop + some cosmetic changes
>>>
>>> committed
>>
>> There are still some pg_upgrade-related failures on the buildfarm, but
>> AFAICT these are not specifically from this feature but more from the
>> test design of the PG_TEST_EXTRA="regress_dump_restore" test.  It looks
>> like we need to drop all users at the end of
>> src/test/regress/sql/graph_table_rls.sql to make this work.
>>
> 
> PFA the patch. I tried using --no-owner with pg_restore and pg_dump
> but that doesn't work since it doesn't exclude policies. I had to add
> "reassign owner to" so that we could retain as many objects as
> possible. Also had to drop the policies which are applicable to users
> being dropped. Reassign doesn't work on policies, ofc.

I have committed this patch, and it seems to be clearing up the 
pg_upgrade test failures on the buildfarm.




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Bug in MultiXact replay compat logic for older minor version after crash-recovery
Next
From: Henson Choi
Date:
Subject: Re: Row pattern recognition