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
Subject: Re: Fix DROP PROPERTY GRAPH "unsupported object class" error
In-reply-to: 
 <CAExHW5sR8tY1JBoG4MGH3pU9A5wq1m4mHZOt0c8wXjcVqZ13sw@mail.gmail.com>
References: <aen77u5go8P7RJaL@bdtpg>
 <CAExHW5vfxVCQFADhiEmi3goyOgGb5qQjURHaM2QDtW6CksUzWA@mail.gmail.com>
 <aet7rawq/V07+H1L@bdtpg>
 <CAExHW5vJGHDXyLDAVC3eJF_ykU73AB9CG6HvJ+WtmO+GE4dnzA@mail.gmail.com>
 <afM8dgqqxsxqmnY7@bdtpg>
 <CAExHW5udMZbMKiQFWB=hDeAK+=t2PXPrmBuscpUc3888kzAi2A@mail.gmail.com>
 <afmHd5vSCJtMFueS@bdtpg> <c948abd3-7483-473c-a0e7-29c579c823fc@gmail.com>
 <afvvNP8b6QEfCNsQ@paquier.xyz>
 <29c33fb6-4200-4a08-be3d-a1a2ceef23b8@eisentraut.org>
 <aiYKqhUZyROUxlVs@paquier.xyz> <200148.1780878520@sss.pgh.pa.us>
 <CAExHW5sR8tY1JBoG4MGH3pU9A5wq1m4mHZOt0c8wXjcVqZ13sw@mail.gmail.com>
Comments: In-reply-to Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
	message dated "Mon, 08 Jun 2026 10:29:09 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <581647.1780944202.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Mon, 08 Jun 2026 14:43:22 -0400
Message-ID: <581648.1780944202@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/581648.1780944202%40sss.pgh.pa.us>
Precedence: bulk

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