On Sun, Oct 15, 2023 at 05:12:58PM -0400, Tom Lane wrote:
> Peter Geoghegan <pg@bowt.ie> writes:
> > 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.
>
> To research this, I looked at every post-dot-zero commit that touched
> src/include/catalog, going back to the 7.4 branch (~ 2003). While
> there are a lot that adjust internal C function declarations or the
> like, there are darn few that touch the catalog data. Ignoring a few
> that just adjusted pg_description entries, I found
>
> 283262cd9 et al
> Fix bogus provolatile/proparallel markings on a few built-in functions
>
> aa7e04cb5 et al
> Clean up some lack-of-STRICT issues in the core code, too
>
> 6e0a053a9
> Correct volatility markings of a few json functions
>
> cb651b624 et al
> Fix incorrect pg_proc.proallargtypes entries for two built-in functions
>
> 0b11a1525 et al
> Mark to_number() and the numeric-type variants of to_char() as stable, not
>
> aed597102
> anyarray really needs to be declared with typalign = 'd', so that entries
> in pg_statistic are correctly aligned if they contain values that require
> double alignment. Too bad we cannot force initdb for this in 7.4 branch.
>
> None of these commits had any side-effects on regression test cases,
> and the log entry for cb651b624 explicitly notes that we didn't add
> the same regression test case as in HEAD for fear that it'd fail with
> older catalog contents.
Commit e568e1e changed pg_rewrite and associated rules.out lines. It could
have avoided the testing effect by modifying rules.sql to pass with or without
the catalog mutation, e.g. by eliminating that output row with an additional
qual on the query. Nobody brought that up in the six intervening years.