[patch] bit XOR aggregate functions

Hi, I personally use it as a checksum for a large unordered set, where performance and simplicity is prioritized over collision resilience. Maybe there are other ways to use them. Best, Alex diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 1ab31a9056..f33358f8db 100644 --- a/

Re: [patch] bit XOR aggregate functions

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 B

Re: [patch] bit XOR aggregate functions

On Wed, Mar 3, 2021 at 7:30 PM Peter Eisentraut < peter.eisentr...@enterprisedb.com> 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 ha

Re: [patch] bit XOR aggregate functions

Hi all, Thanks for your reviews. I've updated my patch to the current master and added a documentation line suggesting using the new function as a checksum. Best regards, Alex On 04/03/2021 17:14, Ibrar Ahmed wrote: On Wed, Mar 3, 2021 at 7:30 PM Peter Eisentraut

Re: [patch] bit XOR aggregate functions

On 05.03.21 13:42, Alexey Bashtanov wrote: Thanks for your reviews. I've updated my patch to the current master and added a documentation line suggesting using the new function as a checksum. committed

Re: [patch] bit XOR aggregate functions

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

Re: [patch] bit XOR aggregate functions

On 3/6/21 8:55 PM, David Fetter wrote: > 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, tha

Re: [patch] bit XOR aggregate functions

On Sat, Mar 06, 2021 at 08:57:46PM +0100, Vik Fearing wrote: > On 3/6/21 8:55 PM, David Fetter wrote: > > 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 > >>> thou

Re: [patch] bit XOR aggregate functions

On 3/6/21 9:00 PM, David Fetter wrote: > On Sat, Mar 06, 2021 at 08:57:46PM +0100, Vik Fearing wrote: >> On 3/6/21 8:55 PM, David Fetter wrote: >>> 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

Re: [patch] bit XOR aggregate functions

On Sat, Mar 06, 2021 at 09:03:25PM +0100, Vik Fearing wrote: > On 3/6/21 9:00 PM, David Fetter wrote: > > On Sat, Mar 06, 2021 at 08:57:46PM +0100, Vik Fearing wrote: > >> On 3/6/21 8:55 PM, David Fetter wrote: > >>> On Wed, Mar 03, 2021 at 03:30:15PM +0100, Peter Eisentraut wrote: > On 10.02.

Re: [patch] bit XOR aggregate functions

On Saturday, March 6, 2021, David Fetter wrote: > > > > 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 */ > > > > > > Why would such an error be necessary,

Re: [patch] bit XOR aggregate functions

On 3/6/21 9:06 PM, David G. Johnston wrote: > On Saturday, March 6, 2021, David Fetter wrote: > >> 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 */ >>>

Re: [patch] bit XOR aggregate functions

ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing napsal: > On 3/6/21 9:06 PM, David G. Johnston wrote: > > On Saturday, March 6, 2021, David Fetter wrote: > > > >> > SELECT BIT_XOR(b ORDER BY a, c).../* works */ > SELECT BIT_XOR(b) OVER (ORDER BY a, c)... /* works */ >

Re: [patch] bit XOR aggregate functions

On 3/7/21 10:53 AM, Pavel Stehule wrote: > ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing > napsal: > >> On 3/6/21 9:06 PM, David G. Johnston wrote: >>> On Saturday, March 6, 2021, David Fetter wrote: >>> >> SELECT BIT_XOR(b ORDER BY a, c).../* works */ >> SELECT BIT_X

Re: [patch] bit XOR aggregate functions

ne 7. 3. 2021 v 11:02 odesílatel Vik Fearing napsal: > On 3/7/21 10:53 AM, Pavel Stehule wrote: > > ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing > > napsal: > > > >> On 3/6/21 9:06 PM, David G. Johnston wrote: > >>> On Saturday, March 6, 2021, David Fetter wrote: > >>> > > >> SELEC

Re: [patch] bit XOR aggregate functions

On 3/7/21 11:05 AM, Pavel Stehule wrote: > ne 7. 3. 2021 v 11:02 odesílatel Vik Fearing > napsal: > >> On 3/7/21 10:53 AM, Pavel Stehule wrote: >>> ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing >>> napsal: >>> On 3/6/21 9:06 PM, David G. Johnston wrote: > On Saturday, March 6, 2021, Davi

Re: [patch] bit XOR aggregate functions

> > And so you are now mandating an ORDER BY on every query and in every > aggregate and/or window function. Users will not like that at all. I > certainly shan't. > The mandatory ORDER BY clause should be necessary for operations when the result depends on the order. You need an order for calcu

Re: [patch] bit XOR aggregate functions

On 3/7/21 11:24 AM, Pavel Stehule wrote: >> >> And so you are now mandating an ORDER BY on every query and in every >> aggregate and/or window function. Users will not like that at all. I >> certainly shan't. >> > > The mandatory ORDER BY clause should be necessary for operations when the > resu

Re: [patch] bit XOR aggregate functions

ne 7. 3. 2021 v 11:28 odesílatel Vik Fearing napsal: > On 3/7/21 11:24 AM, Pavel Stehule wrote: > >> > >> And so you are now mandating an ORDER BY on every query and in every > >> aggregate and/or window function. Users will not like that at all. I > >> certainly shan't. > >> > > > > The mandat

Re: [patch] bit XOR aggregate functions

On 3/7/21 11:37 AM, Pavel Stehule wrote: > ne 7. 3. 2021 v 11:28 odesílatel Vik Fearing > napsal: > >> On 3/7/21 11:24 AM, Pavel Stehule wrote: And so you are now mandating an ORDER BY on every query and in every aggregate and/or window function. Users will not like that at all.

Re: [patch] bit XOR aggregate functions

ne 7. 3. 2021 v 12:39 odesílatel Vik Fearing napsal: > On 3/7/21 11:37 AM, Pavel Stehule wrote: > > ne 7. 3. 2021 v 11:28 odesílatel Vik Fearing > > napsal: > > > >> On 3/7/21 11:24 AM, Pavel Stehule wrote: > > And so you are now mandating an ORDER BY on every query and in every >

Re: [patch] bit XOR aggregate functions

Pavel Stehule writes: > But this is offtopic in this discussion :) The whole topic is off-topic. As a general rule, things that depend on input order shouldn't be declared as aggregates --- they should be window functions or ordered-set aggregates, for which the syntax forces you to specify inpu

Re: [patch] bit XOR aggregate functions

On Sun, 7 Mar 2021 at 23:24, Pavel Stehule wrote: The mandatory ORDER BY clause should be necessary for operations when the result depends on the order. You need an order for calculation of median. And you don't need to know an order for average. More if the result is one number and is not possib

Re: [patch] bit XOR aggregate functions

At Tue, 9 Feb 2021 15:25:19 +, Alexey Bashtanov wrote in > I personally use it as a checksum for a large unordered set, where > performance and simplicity is prioritized over collision resilience. > Maybe there are other ways to use them. FWIW the BIT_XOR can be created using CREATE AGGREGA