Re: Dimension limit in contrib/cube (dump/restore hazard?)

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dimension limit in contrib/cube (dump/restore hazard?)
Date: 2018-08-28 17:18:56
Message-ID: CAPpHfdshw4tFg1RAX3_sdbgeiB7FRCf7wJqKytx6p2=y2VGuxw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

On Tue, Aug 28, 2018 at 6:21 PM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> I belive cube construction from array\arrays should check size of arrays.

Makes sense to me.

> Also there are some unexpected cube dimensionality reduction like in cube_enlarge
> if (n > CUBE_MAX_DIM)
> n = CUBE_MAX_DIM;
> You wanted larger cube, but got cube of another dimension.
>
> I think we should something like this

OK, but I think cube_c_f8() and cube_c_f8_f8() also need to be
revised. Also, I think this behavior should be covered by regression
tests.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Finzel 2018-08-28 17:41:54 Re: Some pgq table rewrite incompatibility with logical decoding?
Previous Message Ashutosh Bapat 2018-08-28 17:13:26 Re: TupleTableSlot abstraction