| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: extend pgbench expressions with functions |
| Date: | 2016-01-29 14:21:19 |
| Message-ID: | alpine.DEB.2.10.1601291514010.6449@sto |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> Also, a comment is needed to explain why such a bizarre
>> condition is used/needed for just the INT64_MIN case.
>
> The last patch I sent has this bit:
> + /*
> + * Some machines throw a floating-point exception
> + * for INT64_MIN % -1, the correct answer being
> + * zero in any case.
> + */
> How would you reformulate that à-la-Fabien?
This one about modulo is fine.
I was refering to this other one in the division case:
+ /* overflow check (needed for INT64_MIN) */
+ if (lval != 0 && (*retval < 0 == lval < 0))
Why not use "if (lval == INT64_MIN)" instead of this complicated
condition? If it is really needed for some reason, I think that a comment
could help.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2016-01-29 14:25:55 | Re: [PATCH] Refactoring of LWLock tranches |
| Previous Message | Artur Zakirov | 2016-01-29 14:20:46 | Re: Fuzzy substring searching with the pg_trgm extension |