On Fri, Oct 30, 2026 at 12:02 AM Robert Haas <[email protected]> wrote: > > On Wed, Oct 28, 2026 at 9:55 AM John Naylor <[email protected]> wrote:
> Yeah, I think most of the time it is, but I suspect it will take only > a few nasty counterexamples to ruin your day. If you can make this > work with every catalog change we've had in the last, idk, 7 years, > then maybe it's worth considering, but I have a feeling that there are > going to be some where it's pretty unpleasant. I'm willing to be > proven wrong. The last 7 years of change has a variety of different problems, so it's a good demo to do. As you say, though, the past does not guarantee the future. > > For complex cases like that, you'd have to have a separate step when > > the system is fully running, and that's after the main row-by-row > > catalog migration has completed (i.e. the merge with the new binary's > > bootstrap data) and after the node trees have been updated. So you can > > allocate OIDs and call ChooseConstraintName() etc. So, it'd be a pain > > in the rear at times, but I don't think it's going to be the same > > level of sadness that some of our users encounter with pg_upgrade. > > I think this only works if you can guarantee that this extra step > succeeds. Otherwise you'd have to roll back after starting the new > system. Okay, here's an idea, continuing with the not-null constraint example: The old way up to version N is a v1 constraint. The N+1 release that introduces the v2 constraint must still recognize the v1 constraint, but all new constraints will be created as v2 constraints. A future release, at least N+2, can drop support for v1 constraints. When the user tries to upgrade off of N+1, the check step complains "The system still has v1 constraints. These must be converted to v2 constraints", and we would have some documented method to do that. This way, complex conversions steps don't need to be happen during an already stressful downtime window and in this case can probably just be DROP and CREATE statements. It has a downside that it puts more responsibility on the user, not to mention the development window with excess complexity, but it would be less risky if complex transforms are not done on-the-fly. -- John Naylor Amazon Web Services
