Re: Skipping schema changes in publication
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Shlok Kyal <shlok.kyal.oss@gmail.com>,
shveta malik <shveta.malik@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>,
"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, YeXiu <1518981153@qq.com>, Ian Lawrence Barwick <barwick@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-02-16T03:20:36Z
Lists: pgsql-hackers
Attachments
- v44-0001-Skip-publishing-the-tables-specified-in-EXCEPT-T.patch (application/octet-stream) patch v44-0001
- v44-0002-Extended-tests-for-EXCEPT-TABLE-patch.patch (application/octet-stream) patch v44-0002
On Thu, 12 Feb 2026 at 13:58, David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Wed, Feb 11, 2026 at 11:58 PM Shlok Kyal <shlok.kyal.oss@gmail.com> wrote:
>>
>>
>> We have addressed the comments in the latest v43 patch.
>
>
> Non-comprehensive review.
>
> Shouldn't the early exits look like:
>
> <begin function>
> if (list_length(publications) < 2)
> return;
>
> perform query here, capture except_publications
>
> if (list_length(except_publications) < 2)
> return;
>
> construct error message and ereport
> <end function>
Modified
>
> + if (publication_has_any_exception(puboid))
> + {
> + except_pub_names = lappend(except_pub_names,
> + makeString(pubform->pubname.data));
> + has_any_exclusion = true;
> + except_pub_id = pubform->oid;
> + }
>
> Either rename has_any_exclusion to has_any_exception or, given how ambiguous that reads in code, maybe standardize on calling these exclusions throughout the code and either just accept we've chosen EXCEPT for the syntax for good reasons or consider whether to EXCLUDING (table1, table2) would be a better choice.
Changed it to has_any_exception
> + errmsg("could not get non excluded table list for table \"%s.%s\" from publisher: %s", -- triple negative; try to avoid "non excluded" as a term - those are "included".
>
> pg_get_publication_effective_tables - the second input argument is an array of publication names so the singular form here is a bit misleading. Should this be subscription-oriented? Otherwise, pg_get_tables_from_publications seems like a more accurate name. "effective" or "only the included ones" seems reasonable to imply.
We have used similarly in the existing pg_get_publication_tables, I
felt the existing might be ok to keep it consistent unless there is a
better consistent name.
> Related, the check in there for "does at least one publication have an exclusion list" makes sense but feels awfully similar to the check for "at most one publication has an exclusion list"...too late for me to figure out what if anything to do make/do about it though.
Ideally this is not expected to happen. But under rare cases it can
happen if the publication is dropped/recreated with except after
creating a subscription. It is better to throw an error in these cases
as we do not allow multiple publications except tables.
Thanks for the comments, the attached v44 version patch has the
changes for the same.
Regards,
Vignesh
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix miscellaneous issues in EXCEPT publication clause.
- 6b0550c45d13 19 (unreleased) landed
-
Change syntax of EXCEPT TABLE clause in publication commands.
- 5984ea868eee 19 (unreleased) landed
-
Add support for EXCEPT TABLE in ALTER PUBLICATION.
- 493f8c6439cf 19 (unreleased) landed
-
Allow table exclusions in publications via EXCEPT TABLE.
- fd366065e06a 19 (unreleased) landed
-
Add wait_for_subscription_sync for TAP tests.
- 0c20dd33db16 16.0 cited