Re: Support EXCEPT for TABLES IN SCHEMA publications - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Support EXCEPT for TABLES IN SCHEMA publications
Date
Msg-id CAA4eK1+G-b+=KqwwakEbpYx995NHRDzXSB-8g-MSDD6NgyReUQ@mail.gmail.com
Whole thread
Responses Re: Support EXCEPT for TABLES IN SCHEMA publications
List pgsql-hackers
On Thu, Jun 11, 2026 at 2:24 AM Zsolt Parragi <zsolt.parragi@percona.com> 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.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Report bytes and transactions actually sent downtream