where EXEC_BACKEND is defined

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

I noticed that when you want to define EXEC_BACKEND, perhaps to do some
non-Windows testing of that option, it's not clear how to do that. I
would have expected it in pg_config_manual.h, but it's actually in
configure.in and in MSBuildProject.pm. So if you want to define it
yourself, you kind of have to make up your own way to do it.

Yeah. Personally, I tend to add the #define to pg_config.h
manually after running configure; I find this convenient because
the effects automatically go away at "make distclean", and I
don't have to remember to undo anything.

I don't see why this should be like that. I propose the attached patch
to move the thing to pg_config_manual.h.

I wouldn't use the option of editing pg_config_manual.h myself, because
of the need to undo it + risk of forgetting and committing that as part
of a patch. Still, this patch doesn't get in the way of continuing to
set it in pg_config.h, and it does offer a place to document the thing
which is a good idea as you say. So no objection here.

One small point is that I believe the existing code has the effect of
"#define EXEC_BACKEND 1" not just "#define EXEC_BACKEND". I don't
think this matters to anyplace in the core code, but it's conceivable
that somebody has extension code written to assume the former.
Nonetheless, I'm +1 for re-standardizing on the latter, because it's
a couple less keystrokes when inserting a manual definition ;-).
Might be worth mentioning in the commit log entry though.

regards, tom lane

On 2020-03-20 17:36, Tom Lane wrote:

One small point is that I believe the existing code has the effect of
"#define EXEC_BACKEND 1" not just "#define EXEC_BACKEND". I don't
think this matters to anyplace in the core code, but it's conceivable
that somebody has extension code written to assume the former.
Nonetheless, I'm +1 for re-standardizing on the latter, because it's
a couple less keystrokes when inserting a manual definition ;-).
Might be worth mentioning in the commit log entry though.

Ok, done that way.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services