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 <vik(at)postgresfriends(dot)org>
> napsal:
>
>> 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.
>>
>
> The safeguard is mandatory ORDER BY clause.

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.
--
Vik Fearing