Re: pgsql: Dissociate btequalimage() from interval_ops, ending its deduplic

On Sat, Oct 14, 2023 at 7:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Noah Misch <noah@leadboat.com> writes:
> > That's right.  We don't have a standard that installcheck of v13.N will have
> > zero diffs on an initdb from v13.0.
>
> Um ... don't we?  I do not recall very many cases where we changed
> initial catalog contents at all in a point release, and I don't think
> any of those cases intentionally created regression diffs.

This did come up in review. I deferred to Noah on the question. FWIW
if I had authored this bugfix, it wouldn't have touched catalog
contents on the backbranches.

> > We've got bigger fish to fry.
>
> True, this isn't going to affect many people either way.  But
> I don't think you've made a good precedent here.

I tend to prefer whatever approach seems least reliant on my having an
accurate understanding of what guarantees exist, and/or what people
actually rely on. It seems to me that there is an asymmetry here: it
is virtually certain that superfluous catalog entries won't bother
anybody, but it is less certain that allowing initdb to produce
different catalog contents in a stable branch is completely harmless.
Why even take a tiny risk if it can be avoided? For that matter why
even bother trying to quantify a risk like that if it can just be
avoided?

--
Peter Geoghegan