From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
---|---|
To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Subject: | Re: Ordering behavior for aggregates |
Date: | 2022-12-13 13:25:04 |
Message-ID: | CAMsGm5cW2ddWAB9=GAhkep9M12EaPvEMiNTwAYcwwkjNWPPtrg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 13 Dec 2022 at 07:50, Vik Fearing <vik(at)postgresfriends(dot)org> wrote:
I am proposing something like pg_aggregate.aggordering which would be an
> enum of behaviors such as f=Forbidden, a=Allowed, r=Required. Currently
> all aggregates would have 'a' but I am thinking that a lot of them could
> be switched to 'f'. In that case, if a user supplies an ordering, an
> error is raised.
>
Although I find "r" attractive, I have two concerns about it:
1) Do we really want to require ordering? I know it's weird and partially
undefined to call something like string_agg without an ordering, but what
if in the specific application it doesn’t matter in what order the items
appear?
2) There is a backward compatibility issue here; it’s not clear to me we
could apply "r" to any existing aggregate.
Actually upon consideration, I think I have similar concerns about "f". We
don’t usually forbid "dumb" things; e.g., I can write a function which
ignores its inputs. And in some situations, "dumb" things make sense. For
example, if I’m specifying a function to use as a filter, it could be
reasonable in a particular instance to provide a function which ignores one
or more of its inputs.
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2022-12-13 13:44:32 | Re: Ordering behavior for aggregates |
Previous Message | houzj.fnst@fujitsu.com | 2022-12-13 13:07:09 | RE: Perform streaming logical transactions by background workers and parallel apply |