Re: pgsql: Dissociate btequalimage() from interval_ops, ending its deduplic
От | Tom Lane |
---|---|
Тема | Re: pgsql: Dissociate btequalimage() from interval_ops, ending its deduplic |
Дата | |
Msg-id | 2124060.1697404378@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Dissociate btequalimage() from interval_ops, ending its deduplic (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: pgsql: Dissociate btequalimage() from interval_ops, ending its deduplic
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: