Re: [patch] bit XOR aggregate functions

From: Vik Fearing <vik(at)postgresfriends(dot)org>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "bashtanov(at)imap(dot)cc" <bashtanov(at)imap(dot)cc>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] bit XOR aggregate functions
Date: 2021-03-07 10:02:46
Message-ID: a0471a48-6212-1976-3a41-c70ce07cf4ee@postgresfriends.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/7/21 10:53 AM, Pavel Stehule wrote:
> ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing <vik(at)postgresfriends(dot)org>
> napsal:
>
>> On 3/6/21 9:06 PM, David G. Johnston wrote:
>>> On Saturday, March 6, 2021, David Fetter <david(at)fetter(dot)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.
>>
>
> I cannot agree with the last sentence. It is questions about costs and
> benefits, but good tool should to make warnings when users does some stupid
> things.
>
> It is important at this time, because complexity in IT is pretty high, and
> a lot of users are not well trained (but well trained people can make
> errors too). And a lot of users have zero knowledge about technology, So
> when it is possible, and when it makes sense, then Postgres should be
> simple and safe. I think it is important for renome too. It is about costs
> and benefits. Good reputation is a good benefit for us too. Ordered
> aggregation was designed for some purposes, and should be used, when it has
> sense.

How many cycles do you recommend we spend on determining whether ORDER
BY a, b is sufficient but ORDER BY a is not?

If we had an optimization_effort_level guc (I have often wanted that),
then I agree that this could be added to a very high level. But we
don't, so I don't want any of it.
--
Vik Fearing

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2021-03-07 10:05:55 Re: [patch] bit XOR aggregate functions
Previous Message Pavel Stehule 2021-03-07 09:53:46 Re: [patch] bit XOR aggregate functions