On Wed, Mar 30, 2022 at 10:04 AM James Coleman <jtc331@gmail.com> wrote:
> Admittedly I hadn't thought of that case. But isn't it already covered
> in the existing docs by the phrase "or an unconstrained domain over
> the new type"? I don't love the word "or" there because there's a
> sense in which the first clause "binary coercible to the new type" is
> still accurate for your example unless you narrowly separate "domain"
> and "type", but I think that narrow distinction is what's technically
> there already.
>
> That being said, I could instead of removing the clause entirely
> replace it with something like "indexes may still need to be rebuilt
> when the new type is a constrained domain".
You're talking about this as if the normal cases is that indexes don't
need to rebuilt, but sometimes they do. However, if I recall
correctly, the way the code is structured, it supposes that the
indexes do need a rebuild, and then tries to prove that they actually
don't. That disconnect makes me nervous, because it seems to me that
it could easily lead to a situation where our documentation contains
subtle errors. I think somebody should go through and study the
algorithm as it exists in the code, and then write documentation to
match it. And I think that when they do that, they should approach it
from the same point of view that the code does i.e. "these are the
conditions for skipping the index rebuild" rather than "these are the
conditions for performing an index rebuild." By doing it that way, I
think we minimize the likelihood of disconnects between code and
documentation, and also make it easier to update in future if the
algorithm gets changed.
--
Robert Haas
EDB: http://www.enterprisedb.com