Re: Skipping schema changes in publication - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Skipping schema changes in publication
Date
Msg-id CAA4eK1+Qv7rbsSs8FgNeNUwzt2cuquPN6b2-QM5XUiYHzJWLsQ@mail.gmail.com
Whole thread
In response to Re: Skipping schema changes in publication  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Skipping schema changes in publication
List pgsql-hackers
On Tue, Feb 17, 2026 at 5:08 PM shveta malik <shveta.malik@gmail.com> wrote:
>
> 10)
> CreatePublication() has changed the way we process publications.
> Earlier, we had explicit checks for publication types such as
> 'for_all_tables' and 'for_all_sequences' etc, which made the code
> easier to follow. That differentiation based on publication type is no
> longer there. As an example,
> we now invoke functions like TransformPubWhereClauses() and
> CheckPubRelationColumnList() even for FOR ALL TABLES ... EXCEPT
> publications, which are not needed. We could consider restoring the
> previous structure, where logic was clearly separated based on
> publication type.
>

Yeah, we can do that if it doesn't add more complexity w.r.t except
clause because the proposed approach tries to unify the code path
where we need to add relations to pg_publication_rel. I think we are
doing some of the new stuff even for all sequences case as well which
is not required for the patch. If we want we can keep a flag
indicating the presence of the except flag in CreatePublicationStmt to
simplify the handling. BTW, the patch doesn't implement EXCEPT clause
for ALL SEQUENCES, is it because we want to deal with that separately
to avoid additional complexity in the patch? Otherwise, I think that
is a natural extension of this work.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Having problems generating a code coverage report
Next
From: shveta malik
Date:
Subject: Re: Skipping schema changes in publication