Re: [patch] bit XOR aggregate functions
Vik Fearing <vik@postgresfriends.org>
From: Vik Fearing <vik@postgresfriends.org>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
David Fetter <david@fetter.org>,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
"bashtanov@imap.cc" <bashtanov@imap.cc>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-03-07T10:02:46Z
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@postgresfriends.org> > napsal: > >> On 3/6/21 9:06 PM, David G. Johnston wrote: >>> On Saturday, March 6, 2021, David Fetter <david@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
Commits
-
Add bit_xor aggregate function
- f9a0392e1cf3 14.0 landed