On 12/12/2017 01:52 PM, Alexander Korotkov wrote:
> On Tue, Dec 12, 2017 at 3:49 PM, Teodor Sigaev <teo...@sigaev.ru
> <mailto:teo...@sigaev.ru>> wrote:
> 
>         Yes, the thing is that we change behavior of existing ~>
>         operator.  In general, this is not good idea because it could
>         affect existing users whose already use this operator. 
>         Typically in such situation, we could leave existing operator as
>         is, and invent new operator with new behavior.  However, in this
>         particular case, I think there are reasons to make an exception
>         to the rules.  The reasons are following:
>         1) The ~> operator was designed especially for knn gist.
>         2) Knn gist support for current behavior is broken by design and
>         can't be fixed.  Most we can do to fix existing ~> operator
>         behavior as is to drop knn gist support.  But then ~> operator
>         would be left useless.
>         3) It doesn't seems that ~> operator have many users yet,
>         because an error wasn't reported during whole release cycle.
> 
>         I hope these reasons justify altering behavior of existing
>         operator as an exception to the rules.  Another question is
>         whether we should backpatch it.  But I think we could leave this
>         decision to committer.
> 
>             I think that this patch is ready for committer.
> 
>     I'm agree with changing behavior of existing ~> operator, but is any
>     objection here? Current implementation is not fixable and I hope
>     that users which use this operator will understand why we change it.
>     Fortunately, the fix doesn't require changes in system catalog.
> 
>     The single question here is about index over expression with this
>     operator, they will need to reindex, which should be noted in
>     release notes.
> 
> 
> Yes.  I bet only few users have built indexes over ~> operator if any. 
> Ask them to reindex in the release notes seems OK for me.
> 

Is there a good way to detect such cases? Either in pg_upgrade, so that
we can print warnings, or at least manually (which would be suitable for
release notes).

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply via email to