On Mon, Nov 15, 2021 at 2:15 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> This is specifically designed not to do any flow control. In the
> backend, we have many instances, where log messages are issued with the
> wrong log level because the stronger log level would have flow control
> impact that is not appropriate at the call site. I don't think we want
> more of that, especially since the flow control requirements in the
> varied suite of frontend programs is quite diverse. Moreover, we also
> require control over the exit codes in some cases, which this kind of
> API wouldn't allow.
I agree that the system we use in the backend isn't problem free, but
making the frontend do something randomly different isn't an
improvement. I think that most people who are writing PostgreSQL
frontend code have also written a lot of backend code, and they are
used to the way things work in the backend. More importantly, there's
an increasing amount of code that wants to run in either environment.
And there have been suggestions that we want to make more things, like
memory contexts, work that way. The design decision that you've made
here makes that harder, and results in stuff like this:
[rhaas pgsql]$ git grep pg_log_fatal.*VA_ARGS
src/bin/pg_rewind/pg_rewind.h:#define pg_fatal(...) do {
pg_log_fatal(__VA_ARGS__); exit(1); } while(0)
src/bin/pg_waldump/pg_waldump.c:#define fatal_error(...) do {
pg_log_fatal(__VA_ARGS__); exit(EXIT_FAILURE); } while(0)
src/include/lib/simplehash.h: do { pg_log_fatal(__VA_ARGS__);
exit(1); } while(0)
Having different frontend utilities each invent their own
slightly-different way of doing this makes it hard to reuse code, and
hard to understand code. We need to find ways to make it more uniform,
not just observe that it isn't uniform today and give up.
IOW, I think the fact that it's not designed to do any flow control is
a bad thing.
--
Robert Haas
EDB: http://www.enterprisedb.com