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

Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
> On Mon, Jun 8, 2026 at 5:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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