Re: (SQL/PGQ) Clean up orphaned properties when dropping a label - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: (SQL/PGQ) Clean up orphaned properties when dropping a label
Date
Msg-id 6fe864a4-a452-452e-845d-ad95385270b6@eisentraut.org
Whole thread
In response to Re: (SQL/PGQ) Clean up orphaned properties when dropping a label  ("zengman" <zengman@halodbtech.com>)
Responses Re: (SQL/PGQ) Clean up orphaned properties when dropping a label
List pgsql-hackers
On 12.06.26 03:36, zengman wrote:
>> Thanks for the report and the patch. The fix is on the right track. I
>> changed a few things as follows
>> a. we usually add operands to the same operator at the end, not at the
>> beginning.
>> b. create_property_graph.sql, which tests all property graph DDLs, is
>> the right place to add these tests. graph_table.sql tests graph query.
>>
>> I have used an existing property graph in create_property_graph.sql in
>> the test. It removes a label from the property graph which has two
>> properties associated with it, one that gets orphaned and one that
>> doesn't. We can verify that the orphaned property gets dropped from
>> the property graph but not the other one by information schema query
>> outputs later. So didn't add any separate verification step after the
>> DDL.
> 
>> Attached patch with those changes.
> 
> Hi Ashutosh,
> 
> Thank you for your assistance. This looks better. There is a small problem that
> 
> https://commitfest.postgresql.org/patch/6848/
> 
> It seems that a 'rebase' is needed to conduct the test normally. Could you please make some adjustments again?

The most recently posted patch does not apply, and if I apply it 
manually, the code change does not appear to cause any changes in the 
test output.  Seemingly, this depends on that some other patches that 
are not shown here?  Please clarify.




pgsql-hackers by date:

Previous
From: Jakub Wartak
Date:
Subject: Re: Allow pg_log_backend_memory_contexts() for postmaster
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] doc: clarify pg_stat_lock.fastpath_exceeded scope