Re: pgsql: Dissociate btequalimage() from interval_ops, ending its deduplic
От | Noah Misch |
---|---|
Тема | Re: pgsql: Dissociate btequalimage() from interval_ops, ending its deduplic |
Дата | |
Msg-id | 20231015013607.61@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: pgsql: Dissociate btequalimage() from interval_ops, ending its deduplic (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Dissociate btequalimage() from interval_ops, ending its deduplic
|
Список | pgsql-committers |
On Sat, Oct 14, 2023 at 08:27:58PM -0400, Tom Lane wrote: > Noah Misch <noah@leadboat.com> writes: > > On Sat, Oct 14, 2023 at 07:45:21PM -0400, Tom Lane wrote: > >> Hmm, I'm not sure that that last is a good idea. The upshot of this > >> (because of the opr_sanity.out change) is that "make installcheck" > >> will fail against existing back-branch installations. That seems > >> more likely to cause problems/confusion than the alternative of just > >> depending on the code change. > > > I'm way more worried about amcheck failing on all those indexes than I am > > about someone who needs to tweak their installcheck rig. > > Well, that's indeed going to be a pain for affected people, but > it doesn't seem like a reason to also break installcheck. That's right. We don't have a standard that installcheck of v13.N will have zero diffs on an initdb from v13.0. Zero diffs would be help a tiny user population, and corrected catalog entries will help a different population. I don't think either choice does enough harm to reopen the decision. We've got bigger fish to fry.
В списке pgsql-committers по дате отправления: