Re: CUBE seems a bit confused about ORDER BY - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: CUBE seems a bit confused about ORDER BY
Date
Msg-id CAPpHfdt_bVoPqZg=yM6rWMAz88xk=+4jH_eJfCyMAdxYMbwwEQ@mail.gmail.com
Whole thread Raw
In response to Re: CUBE seems a bit confused about ORDER BY  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Thu, Jan 11, 2018 at 10:29 PM, Alvaro Herrera <alvherre@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 

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Next
From: Esteban Zimanyi
Date:
Subject: Parameters in user-defined aggregate final functions