Re: Fix DROP PROPERTY GRAPH "unsupported object class" error
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Peter Eisentraut <peter@eisentraut.org>,
Alex Guo <guo.alex.hengchen@gmail.com>,
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2026-06-08T18:43:22Z
Lists: pgsql-hackers
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes: > On Mon, Jun 8, 2026 at 5:58 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> No. At the very least, these messages violate our style guidelines [1]: > My guess is Michael and Tom are referring to two different things. I > guess, the output that Michael refers to is the value of the Identity > column from pg_identify_object() (in create_property_graph.out). I > guess what Tom is referring to is the object description in server > error messages, which uses getObjectDescription() underneath, which in > turn is also called from pg_describe_object(). > create_property_graph.out has outputs from both pg_describe_object() > and pg_identify_object(). It's easy to get confused between outputs of > both when the outputs are pasted without the query which generated the > output. Okay, I see that these are coming from pg_identify_object(), while pg_describe_object() is more verbose. However, I don't think that that ends the discussion, because existing cases in pg_identify_object are not entirely uniform in their succinctness. You quoted some cases that support a minimalistic style, but there are others, notably: case AccessMethodOperatorRelationId produces "operator %d (%s, %s) of %s" while case AccessMethodProcedureRelationId produces "function %d (%s, %s) of %s" case AuthMemRelationId produces "membership of role %s in role %s" (hmm, this one is wrong anyway, since it then translates that string) case UserMappingRelationId produces "%s on server %s" case PublicationNamespaceRelationId produces "%s in publication %s" as does case PublicationRelRelationId Each of these has chosen to include an object-type name so that people won't be totally confused about what's what. So I think we're grading on a curve to some extent here, and it certainly seems to me that these property-graph identifiers are confusing enough that they deserve more than zero info about which identifier is what. I don't think that "C on R" is terribly confusing about the identity of a constraint, but I totally disagree that "property graph label property" is sufficient context to disambiguate "k2 of e of e of create_property_graph_tests.gt". The argument that these only need to be machine-readable doesn't sway me a lot. In the end, any code that is disassembling these strings is going to be written by a human, and the human is a lot more likely to make a mistake about which identifier is which if they're not labeled. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Readable identity strings for property graph objects
- 2a7e95b659df 19 (unreleased) landed
-
Handle element label and label property objects in object address functions
- 72498a86989e 19 (unreleased) landed
-
Simplify code in objectaddress.c for some property graph objects
- 6827de95ee09 19 (unreleased) landed