Re: [patch] bit XOR aggregate functions

ne 7. 3. 2021 v 11:02 odesílatel Vik Fearing <vik@postgresfriends.org>
napsal:

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

The safeguard is mandatory ORDER BY clause.



-- 
> Vik Fearing
>