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

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 →
  1. Fix miscellaneous issues in EXCEPT publication clause.

  2. Change syntax of EXCEPT TABLE clause in publication commands.

  3. Add support for EXCEPT TABLE in ALTER PUBLICATION.

  4. Allow table exclusions in publications via EXCEPT TABLE.

  5. Add wait_for_subscription_sync for TAP tests.