Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jonathan Allen <jallen@americansavingslife.com>
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-26T18:40:57Z
Lists: pgsql-bugs 
Jonathan Allen <jallen@americansavingslife.com> writes:
> Right now I'm using a custom build of ecpg to enable Bigint support, but it would suuuuure be nice to have that working in the next release of postgres.  I agree, all that's missing is the #define HAVE_LONG_LONG_INT 1 line. :)

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.

			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.