Re: Fix DROP PROPERTY GRAPH "unsupported object class" error

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org, Peter Eisentraut <peter@eisentraut.org>
Date: 2026-04-24T14:18:21Z
Lists: pgsql-hackers

Attachments

Hi,

On Fri, Apr 24, 2026 at 05:37:56PM +0530, Ashutosh Bapat wrote:
> So your code changes are needed. However I think the test cases added
> in the patch are not sufficient.
> 1. Earlier in object_address.sql there are instances of property graph
> element, property graph property etc. But I don't see property graph
> element label and property graph label property there.

I did not add them because they would not produce an error without the
patch in place. That said, that's probably better to add them for consistency,
done in the attached.

> 2. In create_graph_table.sql there are tests for pg_describe_object(),
> pg_identify_object_as_address() and pg_identify_object() for property
> graph property, property graph element and property graph label
> objects. But I don't see tests added for the objects covered by the
> patch.
> 
> For create_graph_table.sql I think what we need to do is add a
> RECURSIVE CTE like
> WITH RECURSIVE deps (classid, objid, objsubid, refclassid, refobjid,
> refobjsubid) AS
>  (
>     SELECT classid, objid, objsubid,
>            refclassid, refobjid, refobjsubid
>       FROM pg_depend
>       WHERE refclassid = 'pg_class'::regclass AND
>             refobjid = 'create_property_graph_tests.g2'::regclass
> 
>     UNION ALL
> 
>     SELECT d.classid, d.objid, d.objsubid,
>            d.refclassid, d.refobjid, d.refobjsubid
>       FROM pg_depend d
>       JOIN deps dp ON d.refclassid = dp.classid AND d.refobjid =
> dp.objid AND d.refobjsubid = dp.objsubid
>  )
>  SELECT pg_describe_object(classid, objid, objsubid) as obj,
>        pg_describe_object(refclassid, refobjid, refobjsubid) as reference_graph
>     FROM deps
>     ORDER BY 1, 2;
> 
> for each of the above functions. This query traverses the dependency
> tree thus covering every object that can appear in a property graph.
> For  'create_property_graph_tests.g2' the output of the above query
> 100 rows long which doesn't seem to be worth the code coverage we get.
> I guess, we need to choose a property graph with a smaller dependency
> tree like gt. I haven't examined whether that graph would cover all
> the cases, but it will certainly cover all the objects.

Yeah, gt is enough to cover all the objects. v3 attached makes use of it and
1/ get rid of the "reference_graph" as it's not needed for the test and 2/
use COLLATE "C" in the order by to be on the safe side of things.

> I think the proper description of property graph label property object
> is property graph element label property since we are reporting
> property of an element through a label. But then that means the
> description would be inconsistent with the catalog name and adding
> "element" to the catalog name would make it much longer. I am not able
> to decide whether to add "element" in the description or not, ATM.

I think it's better to be consistent with the current catalog here to stay
focused on the main purpose of this patch.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Readable identity strings for property graph objects

  2. Handle element label and label property objects in object address functions

  3. Simplify code in objectaddress.c for some property graph objects