I wrote:
> BTW, after further digging I am suspicious that this means that we need
> to propagate HAVE_STRTOLL and HAVE_STRTOULL into ecpg_config.h not only
> pg_config.h. I'm not totally sure which compiles include just the former
> not the latter.
After looking closer, ecpg only examines HAVE_STRTOLL and HAVE_STRTOULL
in ecpglib/data.c, which does include the main config file, so we should
be good on that.
> I'm going to wait and see if the buildfarm is unhappy before trying to
> change that, though. It will help prove whether we're actually getting
> useful test coverage.
Nonetheless, all the 32-bit buildfarm critters are falling over, and
the reason is now obvious: HAVE_LONG_LONG_INT isn't getting defined
in the test code, because neither pg_config.h nor ecpg_config.h ever
get included there.
As a stopgap measure, we could stick #include <ecpg_config.h> into
just that one test file. I notice however that there are more problems.
In particular, sqltypes.h supposes it has access to HAVE_LONG_LONG_INT_64,
which seems utterly naive.
It seems like really we need <ecpg_config.h> in sqltypes.h at least,
and if we don't want more bugs of the same ilk in future, it'd be
wise to stick it into something that's included by all ecpg-generated
code, like ecpglib.h. I am however worried about invasion of client
namespace if we do that, so not quite sure what to do here. Thoughts?
regards, tom lane