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