Fabien COELHO <coe...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
