Re: pg_createsubscriber: allow duplicate publication names

> On Jun 2, 2026, at 14:14, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Jun 1, 2026 at 6:42 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>>
>> While testing “Support existing publications in pg_createsubscriber”, I noticed that it doesn’t allow the same publication name even when the publications are from different databases.
>>
>> A simple repro:
>> ```
>> % createdb db1
>> % createdb db2
>> % psql db1 -c 'CREATE PUBLICATION app_pub FOR ALL TABLES'
>> % psql db2 -c 'CREATE PUBLICATION app_pub FOR ALL TABLES'
>> CREATE PUBLICATION
>> CREATE PUBLICATION
>> % pg_createsubscriber --dry-run --pgdata <data-dir> --publisher-server postgres --database db1 --database db2 --publication app_pub --publication app_pub
>> pg_createsubscriber: error: publication "app_pub" specified more than once for --publication
>> ```
>>
>> The rejection is not introduced by this feature, but previously it was not a real problem because the specified publication names would always be created. After this feature, it may become an issue, since the feature intends to use existing publications, and users may have defined publications with the same name in different databases. So the current restriction becomes a limitation of the new feature. I don’t think we should leave this limitation in PG19.
>>
>> Since pg_createsubscriber already ensures that duplicate database names cannot be specified, we can just remove the duplicate publication name check.
>>
>
> Doesn't the same point apply to subscription names? The subscription
> names can be specified by "--subscription=name"
>
> --
> With Regards,
> Amit Kapila.

In theory, yes, since subscription names are also unique per database. I didn’t include that in v1 because the publication-name issue affects the new PG19 feature for reusing existing publications, whereas allowing duplicate subscription names seems like an improvement that could be a material of v20.

As you ask, I put the subscription-name change in 0002. Please decide how to proceed. If you decide to accept both, they can be squashed.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/