Tom Lane wrote:
> >> Since behavior of ~> (cube, int) operator is changed, depending entities
> >> must be refreshed after upgrade. Such as, expression indexes using this
> >> operator must be reindexed, materialized views must be rebuilt, stored
> >> procedures and client code must be revised to correctly use new behavior.
> >> That should be mentioned in release notes.
>
> Was there any real discussion of whether we could get away with that
> in the back branches? My opinion is no. It's not even clear to me
> that this is acceptable in HEAD --- isn't it going to create huge
> problems for pg_upgrade?
This was discussed upthread and the solution found was "objects need to
be rebuilt, indexes need to be reindexed". The point of Alexander's
query was to find affected objects that need such treatment. Teodor
explicitly disregarded any change in pg_upgrade because the database
you're upgrading *from* is supposed to have gotten indexes reindexed,
etc.
> Perhaps some solution to the compatibility problems could be found
> based on giving the cube extension a new version number, and applying
> the behavioral change only upon doing ALTER EXTENSION UPDATE.
Hmm, that's an idea worth exploring, keeping in mind that the bug
affects an operator. I'm not sure it's possible to redefine an operator
(change its underlying function) without dropping it, which would cause
its OID to change. Maybe that's okay, or maybe there's a way around it.
> But it doesn't look like the patch even bumped the extension's version
> number.
As I understand, extension version numbers should change if the SQL
interface changes (the set of objects differ), but should not change if
only the underlying C code changes.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
