From: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: weird GROUPING SETS and ORDER BY behaviour |
Date: | 2024-01-06 16:57:27 |
Message-ID: | CAEzk6fcdQRgLraDkJa_AGWT8ue-CGD_Hd2xQ0t+KsbEo6GpveQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 6 Jan 2024 at 16:22, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Sat, Jan 6, 2024 at 8:38 AM Geoff Winkless <pgsqladmin(at)geoff(dot)dj> wrote:
>> because when gp_conc is 0, it should be ordering by the concat() value.
>
> Something does seem off here with the interaction between grouping sets and order by.
> I'm inclined to believe that using grouping in the order by simply is an unsupported
> concept we fail to prohibit.
That's disappointing.
> You can get the desired result with a much less convoluted order by clause -
> so long as you understand where your nulls are coming from - with:
> ORDER BY
> n nulls first , x nulls first
Ahh, well, yes, that's fine in this instance which (as you may
remember) was a minimal example of the behaviour, but wouldn't be
useful in the real-world situation, where we can have many
potentially-conflicting grouping sets, each set needing to be ordered
consistently internally.
Geoff
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2024-01-06 17:25:25 | Re: abi-compliance-checker |
Previous Message | Joe Conway | 2024-01-06 16:53:24 | Re: Password leakage avoidance |