On Sat, Mar 06, 2021 at 09:03:25PM +0100, Vik Fearing wrote: > On 3/6/21 9:00 PM, David Fetter wrote: > > On Sat, Mar 06, 2021 at 08:57:46PM +0100, Vik Fearing wrote: > >> On 3/6/21 8:55 PM, David Fetter wrote: > >>> On Wed, Mar 03, 2021 at 03:30:15PM +0100, Peter Eisentraut wrote: > >>>> On 10.02.21 06:42, Kyotaro Horiguchi wrote: > >>>>> We already had CREATE AGGREATE at the time, so BIT_XOR can be > >>>>> thought as it falls into the same category with BIT_AND and > >>>>> BIT_OR, that is, we may have BIT_XOR as an intrinsic aggregation? > >>>> > >>>> I think the use of BIT_XOR is quite separate from BIT_AND and > >>>> BIT_OR. The latter give you an "all" or "any" result of the bits > >>>> set. BIT_XOR will return 1 or true if an odd number of inputs are 1 > >>>> or true, which isn't useful by itself. But it can be used as a > >>>> checksum, so it seems pretty reasonable to me to add it. Perhaps > >>>> the use case could be pointed out in the documentation. > >>> > >>> If this is the only use case, is there some way to refuse to execute > >>> it if it doesn't contain an unambiguous ORDER BY, as illustrated > >>> below? > >>> > >>> 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. > > I think one of us is forgetting how XOR works.
Oops. You're right. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
