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 →
  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