Re: CUBE seems a bit confused about ORDER BY

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

Re: CUBE seems a bit confused about ORDER BY

On Thu, Jan 11, 2018 at 10:29 PM, Alvaro Herrera 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

Re: CUBE seems a bit confused about ORDER BY

Tom Lane wrote: > Alvaro Herrera writes: > > 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 > >

Re: CUBE seems a bit confused about ORDER BY

Alvaro Herrera writes: > Tom Lane wrote: >> 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

Re: CUBE seems a bit confused about ORDER BY

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

Re: CUBE seems a bit confused about ORDER BY

Alvaro Herrera writes: > That's true, and I agree we don't necessarily have to find everything. > I still think we should print the pg_depend query in the relnotes, > because those would be the most common cases of objects that need to be > rebuilt. Wait. A. Minute.

Re: CUBE seems a bit confused about ORDER BY

Teodor Sigaev wrote: > > > I think this is useful enough.  The fact remains that we can't check > > very well for functions; maybe suggest a LIKE clause to look for ~> > > anywhere in function source code? > Seems, it's overengineering. It could give a false positive results > and

Re: CUBE seems a bit confused about ORDER BY

Thanks to all, pushed I think this is useful enough.  The fact remains that we can't check very well for functions; maybe suggest a LIKE clause to look for ~> anywhere in function source code?Seems, it's overengineering. It could give a false positive results and doesn't cover all

Re: CUBE seems a bit confused about ORDER BY

On Wed, Jan 10, 2018 at 8:02 PM, Alvaro Herrera wrote: > Teodor Sigaev wrote: > > > SQL-query seems too huge for release notes and isn't looking for > > materialized view (fixable) and functional indexes with function which > > contains this operator somewhere inside

Re: CUBE seems a bit confused about ORDER BY

Teodor Sigaev wrote: > SQL-query seems too huge for release notes and isn't looking for > materialized view (fixable) and functional indexes with function which > contains this operator somewhere inside (not fixable by this query). I > think, just words is enough. But the query can be made a

Re: CUBE seems a bit confused about ORDER BY

On Thu, Dec 14, 2017 at 2:39 PM, Teodor Sigaev wrote: > SQL-query seems too huge for release notes and isn't looking for > materialized view (fixable) and functional indexes with function which > contains this operator somewhere inside (not fixable by this query). I > think,

Re: CUBE seems a bit confused about ORDER BY

SELECT dep.classid::regclass AS class,   CASE WHEN dep.classid = 'pg_catalog.pg_class'::regclass THEN dep.objid::regclass::text        WHEN dep.classid = 'pg_catalog.pg_constraint'::regclass THEN (SELECT conname FROM pg_catalog.pg_constraint WHERE oid = dep.objid)   ELSE NULL   END AS name

Re: CUBE seems a bit confused about ORDER BY

On Thu, Dec 14, 2017 at 1:36 PM, Teodor Sigaev wrote: > 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

Re: CUBE seems a bit confused about ORDER BY

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).

Re: CUBE seems a bit confused about ORDER BY

On 12/12/2017 01:52 PM, Alexander Korotkov wrote: > On Tue, Dec 12, 2017 at 3:49 PM, Teodor Sigaev > wrote: > > Yes, the thing is that we change behavior of existing ~> > operator.  In general, this is not good idea because it could >

Re: CUBE seems a bit confused about ORDER BY

On Tue, Dec 12, 2017 at 3:49 PM, Teodor Sigaev 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

Re: CUBE seems a bit confused about ORDER BY

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. 

Re: CUBE seems a bit confused about ORDER BY

Hi! On Fri, Dec 8, 2017 at 11:21 AM, Andrey Borodin wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed >