Re: where EXEC_BACKEND is defined

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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