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