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
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 |