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

Jonathan Allen <jallen@americansavingslife.com>

From: Jonathan Allen <jallen@americansavingslife.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Meskes <meskes@postgresql.org>, Andrew Gierth <andrew@tao11.riddles.org.uk>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2018-02-27T22:59:18Z
Lists: pgsql-bugs
Thank you!  Thank you so very much.  Using my own private build of ecpg until May will be a bit of a pain but hey - what am I complaining about, right?  I very much look forward to an official build of ecpg that properly handles Bigint right out of the box.

Thanks again for getting that worked out and released into the build pipeline,

-Jonathan

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us] 
Sent: Tuesday, February 27, 2018 2:48 PM
To: Jonathan Allen <jallen@americansavingslife.com>
Cc: Michael Meskes <meskes@postgresql.org>; Andrew Gierth <andrew@tao11.riddles.org.uk>; pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT

I wrote:
> I'm afraid to push this in today, because today is a release wrap day, 
> and there's no time to recover if it turns out that we tickle some 
> portability issue.  But I think we should fix it as soon as the 
> release dust settles.

Pushed now.  Barring buildfarm complaints, it'll be in our May releases.

			regards, tom lane


Commits

  1. Remove configure's check for nonstandard "long long" printf modifiers.

  2. printf("%lf") is not portable, so omit the "l".

  3. Support platforms where strtoll/strtoull are spelled __strtoll/__strtoull.

  4. Arrange to supply declarations for strtoll/strtoull if needed.

  5. Hot-fix ecpg regression test for missing ecpg_config.h inclusion.

  6. Add some test coverage for ecpg's "long long" support.

  7. Recognize that MSVC can support strtoll() and strtoull().

  8. Fix up ecpg's configuration so it handles "long long int" in MSVC builds.