Re: add modulo (%) operator to pgbench

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add modulo (%) operator to pgbench
Date: 2014-08-06 16:02:11
Message-ID: CA+TgmoanEdKEh=hZvjyap2nNWw9+T8_xFS76y5W3RBfYha3EFQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 5, 2014 at 5:53 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Robert Haas wrote:
>> On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>> >> This patch is pretty trivial.
>> > Another slightly less trivial but more useful version.
>> >
>> > The issue is that there are 3 definitions of modulo, two of which are fine
>> > (Knuth floored division and Euclidian), and the last one much less useful.
>> > Alas, C (%) & SQL (MOD) choose the bad definition:-( I really need any of
>> > the other two. The attached patch adds all versions, with "%" and "mod"
>> > consistent with their C and SQL unfortunate counterparts, and "fmod" and
>> > "emod" the sane ones.
>>
>> Three different modulo operators seems like a lot for a language that
>> doesn't even have a real expression syntax, but I'll yield to whatever
>> the consensus is on this one.
>
> I wonder if it would be necessary to offer the division operator
> semantics corresponding to whatever additional modulo operator we choose
> to offer. That is, if we add emod, do we need "ediv" as well?

Maybe we ought to break down and support a real expression syntax.
Sounds like that would be better all around.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2014-08-06 16:15:32 Re: Proposal: Incremental Backup
Previous Message Robert Haas 2014-08-06 15:56:25 Re: Minmax indexes