| From: | Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Support EXCEPT for TABLES IN SCHEMA publications |
| Date: | 2026-06-15 11:30:42 |
| Message-ID: | CABdArM4rxsYpCH325G2b7J8Dq6b9P2t8Hq3hH1xiZmVC+mQYkA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 15, 2026 at 11:38 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Jun 11, 2026 at 2:24 AM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)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.
>
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nisha Moond | 2026-06-15 11:30:50 | Re: Support EXCEPT for TABLES IN SCHEMA publications |
| Previous Message | Henson Choi | 2026-06-15 11:29:19 | Re: LLVM JIT: any JIT-compiled query crashes (SIGILL) on a libLLVM 19 + ASAN build |