Hello,
I do not understand your disagreement. Do you disagree about the
expected>> semantics of fatal? Then why provide fatal if it should not
be used? What is the expected usage of fatal?
I disagree about the fact that pgbench uses pg_log_fatal() in ways
that other binaries don't do.
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…
For example, other things use pg_log_error() followed by an exit(), but
not this code.
Sure.
I am not going to fight hard on that, though.
Me neither.
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.
--
Fabien.
