From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, bashtanov(at)imap(dot)cc, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [patch] bit XOR aggregate functions |
Date: | 2021-03-06 19:55:54 |
Message-ID: | 20210306195554.GG17314@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 03, 2021 at 03:30:15PM +0100, Peter Eisentraut wrote:
> On 10.02.21 06:42, Kyotaro Horiguchi wrote:
> > We already had CREATE AGGREATE at the time, so BIT_XOR can be
> > thought as it falls into the same category with BIT_AND and
> > BIT_OR, that is, we may have BIT_XOR as an intrinsic aggregation?
>
> I think the use of BIT_XOR is quite separate from BIT_AND and
> BIT_OR. The latter give you an "all" or "any" result of the bits
> set. BIT_XOR will return 1 or true if an odd number of inputs are 1
> or true, which isn't useful by itself. But it can be used as a
> checksum, so it seems pretty reasonable to me to add it. Perhaps
> the use case could be pointed out in the documentation.
If this is the only use case, is there some way to refuse to execute
it if it doesn't contain an unambiguous ORDER BY, as illustrated
below?
SELECT BIT_XOR(b ORDER BY a, c)... /* works */
SELECT BIT_XOR(b) OVER (ORDER BY a, c)... /* works */
SELECT BIT_XOR(b) FROM... /* errors out */
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2021-03-06 19:57:46 | Re: [patch] bit XOR aggregate functions |
Previous Message | David Fetter | 2021-03-06 19:11:26 | Public APIs |