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

Hi,

On Wed, Apr 29, 2026 at 06:02:57PM +0530, Ashutosh Bapat wrote:
> On Fri, Apr 24, 2026 at 7:48 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> >
> 
> > > 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.
> >
> > 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 was thinking of modifying the existing queries as attached.

Works for me.

> 
> I think COLLATE "C" is safer, however, it doesn't go well with indexes
> in ORDER BY, which make this query easy to write. (see [1]). So far we
> haven't seen any buildfarm failures so far with the current ORDER BY.
> That makes me think that the query output will be stable even without
> COLLATE "C". So keeping it that way. But we can add COLLATE "C" if we
> see buildfarm instability.

I can see the the instability locally with en_US.UTF-8 (gt before _gt) and I
can see that, for example sifaka, has en_US.UTF-8 in locales. So, modifying the
impacted query a bit to add COLLATE "C" in the attached.

> 2. Used get_catalog_object_by_oid(), which appropriately uses the
> cache or table scan in getObjectIdentityParts(). It performs an extra
> lookup but I think that's ok, since the latter function is not in a
> hot path. I wonder whether get_catalog_object_by_oid() is intended to
> be called whenever we want to get the catalog tuple by OID instead of
> directly calling sys cache lookup function or catalog scan. At least
> the new code you are adding can make use of this function.

v3 was using the syscan to be consistent with what getObjectDescription() was
doing. That makes sense to me to be consistent, so in passing v5 makes use of
get_catalog_object_by_oid() in getObjectDescription() too.

Regards,

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