On Wednesday, October 5, 2011, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> >
> > Excerpts from Robert Haas's message of mar oct 04 10:39:27 -0300 2011:
> > > On Tue, Oct 4, 2011 at 8:15 AM, Michael Meskes <meskes@postgresql.org<javascript:;>>
> wrote:
> >
> > > >> 2010 on Windows, which accepts "long long" to mean the same thing as
> > > >> __int64, but ECPG doesn't recognize the later.
> > > >> May be related to BUG #5464: ecpg on 64bit system converts "long
> long" to
> > > >> "long"
> > > >
> > > > Well, this bug is (at least I don't know otherwise) fixed for more
> than a year.
> > > > Maybe the configure test doesn't work on Windows? I don't know.
> > >
> > > On at least some Windows builds, configure isn't used at all... so
> > > whatever values is being used would come from the MSVC build system.
> >
> > In fact, pg_config.h.win32 does not have the HAVE_LONG_LONG_INT symbol
> > at all -- only HAVE_LONG_LONG_INT_64 is in there.
>
> Is this wrong?
>
> Not sure, but it seems ecpg is the only place in our entire source that
this is used - that's probably why it was missed.
Does ecpg have a different requirement from everything else, or are we just
doing it differently in different places for no special reason?
It was applied as commit 29259531, which apparently changed it from our own
implementation to the autoconf standard. And changed a whole bunch of places
from HAVE_LONG_LONG to HAVE_LONG_LONG_INT. Perhaps it just missed to update
the win32 file?
Just to be completely cetain, what behaviour is it we're looking for, that
is not the same as HAVE_LONG_LONG_INT_64?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
