On Sun, Jul 19, 2026 at 07:09:13AM +0530, Amit Kapila wrote: > On Sat, Jul 18, 2026 at 10:11 PM Jeff Davis <[email protected]> wrote: > > On Sat, 2026-07-18 at 12:10 +0530, Amit Kapila wrote: > > > On Thu, Jul 16, 2026 at 12:06 AM Jeff Davis <[email protected]> > > > > To address Noah's concern: is the concern about the dependency > > > > link, or > > > > about having a database-specific oid in a shared catalog at all? > > ... > > > I feel it is the latter as the former doesn't scale well, since each > > > new db-specific column would need its own bespoke handling instead of > > > the dependency machinery handling it uniformly. I agree with your > > > judgement that it is not a good idea to tackle this in v19, > > > especially > > > because splitting a shared, user-visible catalog is too > > > invasive to land safely this late in the cycle, whereas the > > > subdbid-scoping fix already resolves the actual bug at low risk, > > > leaving the decomposition as a structural cleanup better suited to > > > v20. > > > > OK, should we go ahead and split the pg_subscription catalog for v20 > > then? Maybe pg_subscription (shared) and pg_subscription_db (per- > > database)? > > > > +1, though I am not sure of catalog names. We can brainstorm those > during development.
That works for me. I agree an untracked dependency would be worse than the status quo and worse than splitting the catalog. I don't have a strong objection to the status quo.
