On 3/7/21 11:05 AM, Pavel Stehule wrote: > ne 7. 3. 2021 v 11:02 odesílatel Vik Fearing <v...@postgresfriends.org> > napsal: > >> On 3/7/21 10:53 AM, Pavel Stehule wrote: >>> ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing <v...@postgresfriends.org> >>> napsal: >>> >>>> On 3/6/21 9:06 PM, David G. Johnston wrote: >>>>> On Saturday, March 6, 2021, David Fetter <da...@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. >>>> >>> >>> 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
