|From:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: extend pgbench expressions with functions|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Here is a v34 b & c.
> // comments are not allowed. I'd just remove the two you have.
Back to the eighties!
> It make no sense to exit(1) and then return 0, so don't do that. I
> might write this code as:
> This would get rid of the internal-error case here altogether in favor
> of testing it via an assertion.
I've put assertions instead of exit in some places.
> I think that coerceToInt() should not exit(1) when an overflow occurs;
I think that it should, because the only sane option for the user is to
fix the script and relaunch the bench: counting errors has no added value
for the user.
The attached version does some error handling instead, too bad.
> Now, if rval is out of range of an integer, that is going to overflow
> while trying to see whether it should divide by zero.
I could not find a place where there where such potential issue. If the
value is zero, it cannot overflow when cast to int. If it is not zero but
it overflows, then it is an overflow, so it should overflow. Maybe I
misunderstood your point.
|Next Message||Oleksii Kliukin||2016-03-08 21:16:48||Re: empty array case in plperl_ref_from_pg_array not handled correctly|
|Previous Message||Artur Zakirov||2016-03-08 20:21:03||Re: Proposal: Generic WAL logical messages|