Re: add modulo (%) operator to pgbench

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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 be negative.
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