Re: Add support for specifying tables in pg_createsubscriber. - Mailing list pgsql-hackers

From Shubham Khanna
Subject Re: Add support for specifying tables in pg_createsubscriber.
Date
Msg-id CAHv8Rj+88DRWpuHZyxxAZYhSRtbPUp=XrnsLFcYL6x4XXUM=KA@mail.gmail.com
Whole thread Raw
In response to RE: Add support for specifying tables in pg_createsubscriber.  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
On Wed, Sep 10, 2025 at 8:05 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Wednesday, September 3, 2025 9:58 AM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > Hi Shubham,
> >
> > My first impression of patch v4-0001 was that the new design is adding
> > unnecessary complexity by introducing a new --existing-publication
> > option, instead of just allowing reinterpretation of the --publication
> > by allowing it to name/reuse an existing publication.
> >
> > e.g.
> >
> > Q. What if there are multiple databases, but there's a publication on
> > only one of them? How can the user specify this, given that the rules
> > say there must be the same number of --existing-publication as
> > --database? The rules also say --existing-publication and
> > --publication cannot coexist. So what is this user supposed to do in
> > this scenario?
> >
> > Q. What if there are multiple databases with publications, but the
> > user wants to use the existing publication for only one of those and
> > FOR ALL TABLES for the other one? The rules say there must be the same
> > number of --existing-publication as --database, so how can the user
> > achieve what they want?
> >
> > ~~
> >
> > AFAICT, these problems don't happen if you allow a reinterpretation of
> > --publication switch like Euler had suggested [1]. The dry-run logs
> > should make it clear whether an existing publication will be reused or
> > not, so I'm not sure even that the validation code (checking if the
> > publication exists) is needed.
> >
> > Finally, I think the implementation might be simpler too -- e.g. fewer
> > rules/docs needed, no option conflict code needed.
>
> I'm hesitant to directly change the behavior of --publication, as it seems
> unexpected for the command in the new version to silently use an existing
> publication when it previously reported an ERROR. Although the number of users
> relying on the ERROR may be small, the change still appears risky to me.
>
> I think it's reasonable to introduce an option that allows users to preserve the
> original behavior. If --existing-publication appears too complex, we might
> consider adding a more straightforward option, such as --if-not-exists or
> --use-existing-pub (name subject to further discussion). When this option is
> specified, the command will not report an ERROR if a publication with the
> specified --publication name already exists; instead, it will use the existing
> publication to set up the publisher. If the option is not specified, the original
> behavior will be maintained.
>

As suggested I introduced a new option --if-not-exists. When this
option is specified, if the given --publication already exists, it
will be reused instead of raising an ERROR. If the option is not
specified, the current behavior is preserved, ensuring backward
compatibility.
The attached patch contains the suggested changes.

Thanks and regards,
Shubham Khanna.

Attachment

pgsql-hackers by date:

Previous
From: Jakub Wartak
Date:
Subject: Re: PostgreSQL 18 GA press release draft
Next
From: Richard Guo
Date:
Subject: Re: plan shape work