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 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 */
>>
>>
>> Why would such an error be necessary, or even desirable?
>
> Because there is no way to ensure that the results remain consistent
> from one execution to the next without such a guarantee.

I think one of us is forgetting how XOR works.
--
Vik Fearing