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.
So I beg to differ with Noah: I think we *do* have a policy against
doing this. At least, we've not actually done it in the last twenty
years.
regards, tom lane