On Tue, Sep 9, 2025, at 11:34 PM, Zhijie Hou (Fujitsu) wrote:
> On Wednesday, September 3, 2025 9:58 AM Peter Smith
> <smithpb2250@gmail.com> wrote:
>>
>> 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 don't buy this argument. Every feature that is not supported emits an error.
You can interpret it as (a) we don't support using existing publications until
v18 but we will start support it from now on or (b) it is a hard error that we
shouldn't allow, hence, stop now. I would say this case is (a) rather than (b).
The proposed extra option would do pg_createsubscriber behaves in a different
way if it is specified or not. That's not a good UI. It will cause confusion.
If you are not reading the manual, it isn't intuitive that you need to specify
an extra option until executing it. If you have a good hint message, the second
try can succeed.
--
Euler Taveira
EDB https://www.enterprisedb.com/
