On Fri, Mar 14, 2025 at 12:26 AM Zhijie Hou (Fujitsu) < houzj.f...@fujitsu.com> wrote:
> For logical replication, there is a frequent need to automatically delete > all > objects (including publications) on replicas that are no longer needed. > This > requirement comes from a common use case in logical replication, which is > to > replicate only a subset of database objects. I don't see us implementing an API to provide an alternative to "ALL TABLES"... Personally, I am uncertain about > the use case for retaining only some of the publications while dropping > others. > To assume there is nothing between All or None seems unwise even if we cannot imagine what that may be. > Besides, I am unsure if the rationale behind pg_upgrade's output script is > applicable here. Yeah, I probably shouldn't have mentioned it. I don't need it to explain or support my case. I think the option proposed in this thread is not to handle the > version mismatch between the publisher and the subscriber. Certainly not given that this requires a physical standby as a base and those are not cross-major-version capable. Overall, > I favor automatically deleting publications rather than offering a script > for > manual execution. > > I'm done arguing the counter-point to this. I cannot give this a +1 unless the DBA is given a chance to review and edit the drop commands that we create. But as of now I'm in the minority and this has a committer willing to proceed without this capability. I take some comfort in that it seems at least if they use --dry-run they can see what objects will be dropped. But the editor capability seems more useful. There is always v19 and beyond; at least nothing here precludes adding such a feature in the future. David J.
