On Mon, Jun 15, 2026 at 11:38 AM Amit Kapila <[email protected]> wrote: > > On Thu, Jun 11, 2026 at 2:24 AM Zsolt Parragi <[email protected]> > wrote: > > > > > Let's wait for feedback from others. > > > > Yes, I think that's the best approach for this question. > > > > > Right, As also mentioned above, ALTER TABLE changes that affect > > > publication membership currently do not emit any notice or warning, so > > > I'm not sure we need one here either. > > > > My idea was to make this change both for existing cases and new cases > > in this patch, so it would be consistent, but that wasn't exactly > > clear in my previous email, sorry about that. Similarly to how cascade > > reports additional objects being dropped. > > > > IIUC, the objects here we are talking about are removed because of > their dependency type AUTO at least the existing case of 'drop table'. > So, I think the current behavior suggested by Nisha sounds correct and > consistent with the pre-existing 'drop table' case. Also, we display > such case at DEBUG2 level, see following code in dependency.c: > > if (extra->flags & (DEPFLAG_AUTO | > DEPFLAG_INTERNAL | > DEPFLAG_PARTITION | > DEPFLAG_EXTENSION)) > { > /* > * auto-cascades are reported at DEBUG2, not msglevel. We don't > * try to combine them with the regular message because the > * results are too confusing when client_min_messages and > * log_min_messages are different. > */ > ereport(DEBUG2, > (errmsg_internal("drop auto-cascades to %s", > > We can consider displaying such a message for schema cases, if not > already there. >
The DROP TABLE case is handled automatically via dependency cascade, so we already get above DEBUG2 log. However, when a table is moved to a different schema, no such log is emitted because schema changes are outside the scope of dependency cascade processing. In v13, I added a DEBUG2 message when a table is removed from the exclusion list due to a schema change. -- Thanks, Nisha
