Horton

Re: [patch] bit XOR aggregate functions

Vik Fearing <vik@postgresfriends.org>

View thread View on postgr.es
From: Vik Fearing <vik@postgresfriends.org>
To: "David G. Johnston" <david.g.johnston@gmail.com>, David Fetter <david@fetter.org>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "bashtanov@imap.cc" <bashtanov@imap.cc>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-03-07T09:36:35Z
Lists: pgsql-hackers 
On 3/6/21 9:06 PM, David G. Johnston wrote:
> On Saturday, March 6, 2021, David Fetter <david@fetter.org> 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, 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.
>>
> 
> Numerous existing aggregate functions have this behavior.  Making those
> error isn’t an option.  So is making this a special case something we want
> to do (and also maybe make doing so the rule going forward)?

Aside from the fact that bit_xor() does not need this, I am opposed to
it in general.  It is not our job to make people write correct queries.
-- 
Vik Fearing

Commits

  1. Add bit_xor aggregate function