Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>>> So my opinion is that this small modulo operator patch is both useful and
>>> harmless, so it should be committed.
>>
>> You've really failed to make that case --- in particular, AFAICS there is
>> not even consensus on the exact semantics that the operator should have.
>
> There is. Basically whatever with a positive remainder when the divisor is
> positive is fine. The only one to avoid is the dividend signed version,
> which happen to be the one of C and SQL, a very unfortunate choice in both
> case as soon as you have negative numbers.
No, it depends totally on the application. For financial and
physical inventory purposes where I have had occasion to use it,
the properties which were important were:
Assuming that all values are integers, for:
x = a / b; y = a % b;
If b is zero either statement must generate an error. If a and b have the same sign, x must be positive; else x must
benegative. It must hold that abs(x) is equal to abs(a) / abs(b). It must hold that ((x * b) + y) is equal to a.
This is exactly what the languages I was using did, and I was glad.
I find it convenient that C and SQL behave this way. You are
proposing that these not all hold, which in a lot of situations
could cause big problems. You seem familiar enough with your own
use case that I believe you when you say you don't want these
semantics, but that just points out the need to support both.
>> Then we could add a modulo operator with whatever semantics seem
>> most popular, and some function(s) for the other semantics, and
>> there would not be so much riding on choosing the "right"
> semantics.
>
> The semantics is clear.
I disagree.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company