The xor operator emulation for postgres is in the process of being corrected to behave like a true binary operator, meaning that 1 ^ 1 ^ 1 will be true for Postgres.
In order to keep what some regard as “true” xor behaviour between nary operands, do we want to keep the current Postgres emulation as a separate database function? I agree that we shouldn’t provide every possible conceived utility function so wanted to ask here first.
If so what should it be called “xor()” or another suggestion “exactly_one()”?
I think this is the kind of tiny, unlikely-to-be-popular utility that’s better to share via a code snippet, perhaps in a forum or blog post. We’ve resisted adding complete coverage of database functions and I think this would fit in the same bucket.
Thanks I agree but it’s good to get closure on that thread
It’s an unfortunate change for my team as we use the old behaviour a lot but have never had the need for the new “return true if an odd number of operands are true” behaviour… oh well
Sorry @shangxiao for not answering sooner! I’m just catching up with email after the feature freeze and alpha release. I believe is too late now , but if consensus is reached, I’m happy to help you push this forward!
Personally, I did expect the xor to be exactly one until we had the enlightening conversation in the PR, and I think it would be handy to have such functionality in the ORM. Though regarding naming, that’s a tough one! I asked chatGPT about this and it gave me many confusing answers, so I’m not sure there is a “standard name” for this operation.
I think I’ll just add a gist or something to share with people (or maybe even a django-extensions extension like I suggested to the other person ). A doc note or a section in “topics” about combining xor (^) expressions isn’t what people may expect could also be nice, along with an example function to copy-paste.
Re naming; My opinion is that XOR is fine – as a function that takes n arguments – nary XOR should be exclusive as the name suggests