RE: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT

Hi,

Thanks for working a lot in this thread.

> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 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 agreed.

> > 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.

You have done it as the "hot-fix", thanks.
Also thanks for fixing the failed of "Buildfarm member dromedary".
# I also feel curious about it.

> 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?

I am also inclined to the above, by the way.

>> Is this another problem in linux? Or am I wrong something?
>
> That would depend on what platform you're running on: if it's 64-bit
> then "long int" is probably 64 bits wide, making that a perfectly valid answer.

Thanks, I was misunderstood.


Thanks and best regards,
---
Dang Minh Huong
NEC Solution Innovators, Ltd.
http://www.nec-solutioninnovators.co.jp/en/