On Tue, Jul 27, 2021 at 11:45:07AM +0200, Fabien COELHO wrote:
> Sure. Then what should be the expected usage of fatal? Doc says:
>
> * Severe errors that cause program termination. (One-shot programs may
> * chose to label even fatal errors as merely "errors". The distinction
> * is up to the program.)
>
> pgbench is consistent with the doc. I prefer fatal for this purpose to
> distinguish these clearly from recoverable errors, i.e. the programs goes on
> despite the error, or at least for some time. I think it is good to have
> such a distinction, and bgpench has many errors and many fatals, although
> maybe some error should be fatal and some fatal should be error.
Hm? Incorrect option values are recoverable errors, no? The root
cause of the problem is the user. One can note that pg_log_fatal() vs
pg_log_error() results in a score of 54 vs 50 in src/bin/pgbench/, so
I am not quite sure your last statement is true.
>> That's a set of inconsistences I bumped into while plugging in
>> option_parse_int()
>
> Which is a very good thing! I have already been bitten by atoi.
By the way, if you can write a patch that makes use of strtodouble()
for the float option parsing in pgbench with the way you see things,
I'd welcome that. This is a local change as only pgbench needs to
care about that.
--
Michael
