On Thu, Jan 11, 2018 at 10:29 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> Tom Lane wrote: > > What we've done in the past for comparable situations is to make the > > change in a new major version and teach pg_upgrade to detect and report > > the need for changes --- in this case, it might do something like create > > a script of REINDEX commands for the affected indexes. See e.g. > > old_9_6_invalidate_hash_indexes(). > > I think the whole point is that any knn-gist indexes using this operator > are completely broken (i.e. they return the wrong answer), so leaving > them as-is in existing branches is not cool. > > The idea of an extension update being the trigger for a fix sounds > reasonable. Maybe we can have the current function under ~> that throws > a WARNING each time it is invoked, inviting people to upgrade the > extension; and the new extension would contain a new ~> with the right > semantics. Then all the magic to rebuild objects has to occur in the > upgrade .sql script. Yes, the point is that ~> operator was especially designed to get knn-gist support. However, its design was broken. And operator with that behavior can't be accelerated using knn-gist. We could leave this operator "as is", but drop its knn-gist support. But that would be discouraging since then ~> operator would be left almost useless. Assuming that ~> operator seems to not being heavily used (bug report was received after more than year after release), I proposed to change operator behavior so that it can be accelerated by knn-gist. I like Alvaro's proposal about extension upgrade. Assuming that there are not many users of ~>, and even smaller amount of them has built depending objects over ~> operator, I'd like to propose to not invent magic in upgrade .sql script. In .sql script can just do DROP OPERATOR, and CREATE OPERATOR with new function. If depending objects exist then this script will trigger an error. Given this error, user can manually drop depending objects before entension upgrade. Anyway, assuming that behavior of ~> operator was changed, depending objects need to be adjusted not just rebuilt. So, magic would unlikely work in this case. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
