Re: Fix DROP PROPERTY GRAPH "unsupported object class" error
| От | Michael Paquier |
|---|---|
| Тема | Re: Fix DROP PROPERTY GRAPH "unsupported object class" error |
| Дата | |
| Msg-id | af0M_NSrfxUDkUeY@paquier.xyz обсуждение |
| Ответ на | Re: Fix DROP PROPERTY GRAPH "unsupported object class" error (Peter Eisentraut <peter@eisentraut.org>) |
| Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: