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 >

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On Wed, Nov 29, 2017 at 3:10 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > I'll try to provide meaningful review next week. >> > > Cool, thanks. > Andrey Borodin complained through Telegram that he can't apply my patches using "git apply". After investigation of this problem, it

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On Wed, Nov 29, 2017 at 7:59 PM, Alexander Korotkov wrote: > Sure, patch got some review. I've no objection against moving this to the > next commitfest though. Please note that as this is qualified as a bug fix, I was not going to mark it as returned with feedback or

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

Hi! On Wed, Nov 29, 2017 at 2:32 PM, Andrey Borodin wrote: > 29 нояб. 2017 г., в 15:59, Alexander Korotkov > написал(а): > > > Sure, patch got some review. I've no objection against moving this to the > next commitfest though. > Since, these

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

> 29 нояб. 2017 г., в 15:59, Alexander Korotkov > написал(а): > > > Sure, patch got some review. I've no objection against moving this to the > next commitfest though. > Since, these patches include bug fix, it's possible that someone will commit > it before next

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On Wed, Nov 29, 2017 at 1:30 PM, Tomas Vondra wrote: > On 11/29/2017 06:13 AM, Michael Paquier wrote: > > On Tue, Nov 21, 2017 at 7:07 AM, Alexander Korotkov > > wrote: > >> On Mon, Nov 20, 2017 at 1:59 PM, Alexander Korotkov > >>

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On 11/29/2017 06:13 AM, Michael Paquier wrote: > On Tue, Nov 21, 2017 at 7:07 AM, Alexander Korotkov > wrote: >> On Mon, Nov 20, 2017 at 1:59 PM, Alexander Korotkov >> wrote: >>> >>> On Mon, Nov 20, 2017 at 4:09 AM, Tomas Vondra >>>

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On Tue, Nov 21, 2017 at 7:07 AM, Alexander Korotkov wrote: > On Mon, Nov 20, 2017 at 1:59 PM, Alexander Korotkov > wrote: >> >> On Mon, Nov 20, 2017 at 4:09 AM, Tomas Vondra >> wrote: >>> >>> Seems fine to me,

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On Mon, Nov 20, 2017 at 1:59 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Mon, Nov 20, 2017 at 4:09 AM, Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > >> Seems fine to me, although perhaps it should be split into two parts. >> One with the cube_coord_llur fixes, and

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On 10/30/2017 03:04 PM, Alexander Korotkov wrote: > On Sun, Oct 29, 2017 at 1:30 AM, Alexander Korotkov > > wrote: ... > > Thus, I heard no objection to my approach.  Attached patch changes ~> > operator in the proposed way and fixes