On Thu, May 07, 2026 at 11:00:48AM +0200, Peter Eisentraut wrote:
> (But you still have the previous name in the commit message.)
(Yes, I did not bother edit the commit message.)
> I had left out these two catalogs from the object address handling
> semi-intentionally. It's not clear to me what an event trigger would want
> to do with this, or whether they should. These catalog layouts are
> implementation details, and if we expose this to event triggers, are we
> locked into this catalog layout? Do we need to document catalog changes as
> breaking user interfaces?
>
> Obviously, we shouldn't leave "unsupported object class" errors lying
> around, but I wonder whether we could also go the other way and
> intentionally skip these catalogs.
Skipping them feels a bit weird to me as objectaddress.c acts as an
interface to make a bit readable catalog dependencies. It's true that
we are in a weird spot in this representation due to the way these two
properties are stored in the catalogs, but if we can make the text
presented to the reader less confusing that seems like a benefit to
me. You have much more context than myself here, of course, so
perhaps my impression is wrong.
--
Michael
