Fix DROP PROPERTY GRAPH "unsupported object class" error

First seen: 2026-04-22 16:19:26+00:00 · Messages: 17 · Participants: 5

Latest Update

2026-06-04 · claude-opus-4-6

Monthly Summary: Fix DROP PROPERTY GRAPH "unsupported object class" error — May 2026

Problem Statement

PostgreSQL's SQL/PGQ Property Graph feature (authored by Peter Eisentraut) introduces catalogs pg_propgraph_element_label and pg_propgraph_label_property that participate in pg_depend but were never registered in the object-address machinery (objectaddress.c). Under normal DROP PROPERTY GRAPH this is latent, but when an event trigger is active, pg_event_trigger_dropped_objects() calls getObjectTypeDescription()/getObjectIdentityParts() for every dropped sub-object, hitting the default switch arm and aborting with ERROR: unsupported object class %u.

Key Developments

Early Iterations (v1–v6): Fix and Expand

Bertrand Drouvot authored the patch, which adds switch arms for both catalogs in getObjectTypeDescription(), getObjectIdentityParts(), and the ObjectProperty[] table. During review, Ashutosh Bapat drove several significant refinements:

An incidental discovery — property graphs were spuriously generating composite/array types — spawned a separate fix (commit 891a57c7394).

Michael Paquier's Intervention: Partial Commit + Pushback

Michael committed the getObjectDescription() refactoring (converting to get_catalog_object_by_oid()) as an independent commit, decoupling it from the remaining fix. He then reopened two points:

  1. Naming: Pushed back on "element label property", preferring catalog-aligned "property graph label property".
  2. Identity ambiguity: Flagged that when element and label share a name (e.g., both e), the identity string produces confusing "k1 of e of e of ..." — correct but unreadable without role keywords.

He posted v7 reflecting catalog-aligned naming, pending Peter's input.

Peter Eisentraut's Response: A Third Option

Peter revealed the omission was semi-intentional and proposed a fundamentally different approach:

On naming, Peter sided with Michael ("property graph label property"), effectively rejecting Ashutosh's hierarchy-based proposal.

Michael pushed back on the skip proposal, arguing objectaddress.c exists precisely to make catalog dependencies legible, and suppressing sub-objects defeats that purpose.

Current State (End of May)

The thread is blocked on a three-way design decision pending Peter's final call:

Option Proponent Trade-off
Describe with full hierarchy Ashutosh Rich identity, exposes layout as contract
Describe tracking catalog name Michael, Peter (if describing) Simpler text, still exposes layout
Skip these catalogs entirely Peter Preserves refactoring freedom, loses event-trigger visibility

The uncontroversial getObjectDescription() refactor has been committed. The core bug fix (v7) awaits resolution of skip-vs-describe.

Architectural Significance

The thread surfaced a broader design principle: wiring decomposed sub-catalogs into objectaddress.c commits the project to that decomposition as a user-visible contract. This generalizes beyond property graphs to any feature using multiple implementation catalogs linked via pg_depend.

History (1 prior analysis)
2026-06-04 · claude-opus-4-6

What's New in This Round

Ashutosh and Michael have both responded to Peter's "skip these catalogs entirely" proposal from the previous round, and both reject it — forming a unified front that pushes back against Peter's position.

1. Ashutosh's counter-argument: event triggers need these objects for DDL replication

Ashutosh provides the first concrete use case for why these sub-objects must be visible through the object-address machinery:

"The objects in those two catalogs can be manipulated using ALTER PROPERTY GRAPH ... ALTER VERTEX/EDGE TABLE ... subcommands. If an event trigger is used to keep copies of the same property graph on multiple different clusters (logical replicas?) in sync, they will need to be handed over these objects."

This directly addresses Peter's API-stability concern by showing that the sub-objects aren't just internal decomposition artifacts — they are independently manipulable via DDL, which means event triggers legitimately need to report them.

2. Ashutosh challenges the generality of Peter's abstraction-boundary argument

Ashutosh argues Peter's concern about locking in catalog layout applies universally, not specifically to property graphs:

"If we change the layout of any catalog that is supported by getObjectDescriptor(), the event trigger working on that object may require a change. Isn't that true already?"

He points out that FormData_pg_* structures already constitute a user-visible contract, so adding these two catalogs to object-address doesn't create a novel problem — it's the same contract every other supported catalog already has.

3. Michael explicitly endorses Ashutosh's position

Michael's "+1" and statement that "deciding to skip these catalogs for the object descriptions still looks like an inconsistent move compared to all the other catalogs" confirms he stands with Ashutosh against Peter's skip proposal.

Net State

The "skip entirely" option (Peter's proposal from last round) now faces 2-against-1 opposition. The remaining decision is purely about naming/formatting — and on that front, Peter and Michael already agreed on the simpler "property graph label property" (catalog-tracking) convention. Unless Peter insists on the skip approach despite pushback, the path forward is likely v7's catalog-aligned naming with whatever identity-string disambiguation is needed. The ball is back with Peter.