pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
11+ messages / 5 participants
[nested] [flat]

Commits from this thread:
  2018-05-19 06f66cff9e a5be529aaa 22d22e4bdd 7329af6b9e 8109f201da 91f3bcc9e4  Support platforms where strtoll/strtoull are spelled __strtoll/__strtoull.
  2018-05-19 95fef6e82a c964c21471 4ffd7909c6 e9f475f991 a6228128fc 023aa76e19  Arrange to supply declarations for strtoll/strtoull if needed.
  2018-05-18 5e79405d82 e55a5516de 4ca492425c bc8656cf98 54ae787ca7 d73857d571  Hot-fix ecpg regression test for missing ecpg_config.h inclusion.
  2018-05-18 e75c832b29 9d6616708d d9cbe9c9fc dbccdd375b ec99e9aa11 e21085da56  Add some test coverage for ecpg's "long long" support.
  2018-05-18 25caeae8d2  Recognize that MSVC can support strtoll() and strtoull().
* BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-23 03:14  PG Bug reporting form <noreply@postgresql.org>
  0 siblings, 1 reply; 11+ messages in thread

From: PG Bug reporting form @ 2018-02-23 03:14 UTC (permalink / raw)
  To: pgsql-bugs@lists.postgresql.org; +Cc: jallen@americansavingslife.com

The following bug has been logged on the website:

Bug reference:      15080
Logged by:          jonathan allen
Email address:      jallen@americansavingslife.com
PostgreSQL version: 10.2
Operating system:   Windows 10 x64
Description:        

I'm trying to access a bigint column on windows using ecpg and I get the
following error:

SQL error: unsupported type "long long" on line x

I found ecpg_get_data() is the call generating the error, and there's a
block of code being skipped because HAVE_LONG_LONG_INT is not defined.  

I found the following code in pg_config.h and tried adding the 3rd line
(#define HAVE_LONG_LONG_INT 1)...

/* Define to 1 if `long long int' works and is 64 bits. */
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#define HAVE_LONG_LONG_INT 1
#endif

Then I tried recompiling postgres from source and copying over the new bin,
lib, include and shared directories...but no luck, my program is still
throwing the same error.  I asked on the #postgresql irc channel and
RhodiumToad and xocolatl said that if I reported this as a bug paquier would
see this and he'd be the person to ask about it.  

I'd really like to be able to get a fix going that I can compile and use
myself until a new public release is available - this bug has brought our
postgres migration to a standstill, it's a real show stopper. :(

Thank you for looking into this and hopefully pointing me in the right
direction. :)

-Jonathan



^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-24 14:43  Michael Meskes <meskes@postgresql.org>
  parent: PG Bug reporting form <noreply@postgresql.org>
  0 siblings, 1 reply; 11+ messages in thread

From: Michael Meskes @ 2018-02-24 14:43 UTC (permalink / raw)
  To: jallen@americansavingslife.com; pgsql-bugs@lists.postgresql.org

> I found ecpg_get_data() is the call generating the error, and there's
> a
> block of code being skipped because HAVE_LONG_LONG_INT is not
> defined.  
> 
> I found the following code in pg_config.h and tried adding the 3rd
> line
> (#define HAVE_LONG_LONG_INT 1)...
> 
> /* Define to 1 if `long long int' works and is 64 bits. */
> #if (_MSC_VER > 1200)
> #define HAVE_LONG_LONG_INT_64 1
> #define HAVE_LONG_LONG_INT 1
> #endif

ECPG does not use pg_config.h, try making your change in ecpg_config.h
instead.

> throwing the same error.  I asked on the #postgresql irc channel and
> RhodiumToad and xocolatl said that if I reported this as a bug
> paquier would
> see this and he'd be the person to ask about it.  

Well, I'm not Michael Paquier and I don't know know why he would be the
person to ask about this, but I guess you don't mind me answering in
his stead.

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-24 19:09  Andrew Gierth <andrew@tao11.riddles.org.uk>
  parent: Michael Meskes <meskes@postgresql.org>
  0 siblings, 2 replies; 11+ messages in thread

From: Andrew Gierth @ 2018-02-24 19:09 UTC (permalink / raw)
  To: Michael Meskes <meskes@postgresql.org>; +Cc: jallen@americansavingslife.com; pgsql-bugs@lists.postgresql.org

>>>>> "Michael" == Michael Meskes <meskes@postgresql.org> writes:

 Michael> ECPG does not use pg_config.h, try making your change in
 Michael> ecpg_config.h instead.

Aha.

Solution.pm has this:

	if (IsNewer(
			'src/interfaces/ecpg/include/ecpg_config.h',
			'src/interfaces/ecpg/include/ecpg_config.h.in'))
	{
		print "Generating ecpg_config.h...\n";
		open(my $o, '>', 'src/interfaces/ecpg/include/ecpg_config.h')
		  || confess "Could not open ecpg_config.h";
		print $o <<EOF;
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#define ENABLE_THREAD_SAFETY 1
EOF
		print $o "#endif\n";
		close($o);
	}

from which HAVE_LONG_LONG_INT seems to be suspiciously missing?

-- 
Andrew (irc:RhodiumToad)




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-24 19:21  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Andrew Gierth <andrew@tao11.riddles.org.uk>
  1 sibling, 0 replies; 11+ messages in thread

From: Tom Lane @ 2018-02-24 19:21 UTC (permalink / raw)
  To: Andrew Gierth <andrew@tao11.riddles.org.uk>; +Cc: Michael Meskes <meskes@postgresql.org>; jallen@americansavingslife.com; pgsql-bugs@lists.postgresql.org

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> Solution.pm has this:

> #if (_MSC_VER > 1200)
> #define HAVE_LONG_LONG_INT_64 1
> #define ENABLE_THREAD_SAFETY 1
> #endif

> from which HAVE_LONG_LONG_INT seems to be suspiciously missing?

I remember noticing that discrepancy recently when I was chasing something
else about int64 support.  It certainly looks wrong, but not being much of
an ecpg user I was hesitant to touch it.

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-24 19:49  Michael Meskes <meskes@postgresql.org>
  parent: Andrew Gierth <andrew@tao11.riddles.org.uk>
  1 sibling, 1 reply; 11+ messages in thread

From: Michael Meskes @ 2018-02-24 19:49 UTC (permalink / raw)
  To: Andrew Gierth <andrew@tao11.riddles.org.uk>; +Cc: jallen@americansavingslife.com; pgsql-bugs@lists.postgresql.org

> Solution.pm has this:
> ...
> from which HAVE_LONG_LONG_INT seems to be suspiciously missing?

Right, but it is missing in pg_config.h, too, right? I have no personal
experience with the Windows build, so I cannot tell if it should be
defined.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-24 20:03  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Michael Meskes <meskes@postgresql.org>
  0 siblings, 1 reply; 11+ messages in thread

From: Tom Lane @ 2018-02-24 20:03 UTC (permalink / raw)
  To: Michael Meskes <meskes@postgresql.org>; +Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>; jallen@americansavingslife.com; pgsql-bugs@lists.postgresql.org

Michael Meskes <meskes@postgresql.org> writes:
>> Solution.pm has this:
>> ...
>> from which HAVE_LONG_LONG_INT seems to be suspiciously missing?

> Right, but it is missing in pg_config.h, too, right?

No, it does get defined on Unix builds (if appropriate), both in
pg_config.h and ecpg_config.h.  As far as I can see in a quick
grep, the core code doesn't use that symbol anywhere anyway ...
but ecpg does.  It's the fact that ecpg_config.h gets the
symbol defined on Unix builds but not MSVC builds that Andrew
is on about.

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-24 20:12  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 11+ messages in thread

From: Tom Lane @ 2018-02-24 20:12 UTC (permalink / raw)
  To: Michael Meskes <meskes@postgresql.org>; +Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>; jallen@americansavingslife.com; pgsql-bugs@lists.postgresql.org

I wrote:
> Michael Meskes <meskes@postgresql.org> writes:
>> Right, but it is missing in pg_config.h, too, right?

> No, it does get defined on Unix builds (if appropriate), both in
> pg_config.h and ecpg_config.h.

Oh, wait, now I see what you meant: there is no stanza like

#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT 1
#endif

in pg_config.h.win32.  I agree that there should be.  As I said, none
of the core backend cares at the moment ... but someday, that discrepancy
is going to bite us.

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* RE: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-26 18:28  Jonathan Allen <jallen@americansavingslife.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 11+ messages in thread

From: Jonathan Allen @ 2018-02-26 18:28 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; Michael Meskes <meskes@postgresql.org>; +Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>

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

-Jonathan

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

I wrote:
> Michael Meskes <meskes@postgresql.org> writes:
>> Right, but it is missing in pg_config.h, too, right?

> No, it does get defined on Unix builds (if appropriate), both in 
> pg_config.h and ecpg_config.h.

Oh, wait, now I see what you meant: there is no stanza like

#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT 1
#endif

in pg_config.h.win32.  I agree that there should be.  As I said, none of the core backend cares at the moment ... but someday, that discrepancy is going to bite us.

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-26 18:40  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Jonathan Allen <jallen@americansavingslife.com>
  0 siblings, 1 reply; 11+ messages in thread

From: Tom Lane @ 2018-02-26 18:40 UTC (permalink / raw)
  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>

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




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-27 21:48  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 11+ messages in thread

From: Tom Lane @ 2018-02-27 21:48 UTC (permalink / raw)
  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>

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




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* RE: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
@ 2018-02-27 22:59  Jonathan Allen <jallen@americansavingslife.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 11+ messages in thread

From: Jonathan Allen @ 2018-02-27 22:59 UTC (permalink / raw)
  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>

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




^ permalink  raw  reply  [nested|flat] 11+ messages in thread


end of thread, other threads:[~2018-02-27 22:59 UTC | newest]

Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-02-23 03:14 BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT PG Bug reporting form <noreply@postgresql.org>
2018-02-24 14:43 ` Michael Meskes <meskes@postgresql.org>
2018-02-24 19:09   ` Andrew Gierth <andrew@tao11.riddles.org.uk>
2018-02-24 19:21     ` Tom Lane <tgl@sss.pgh.pa.us>
2018-02-24 19:49     ` Michael Meskes <meskes@postgresql.org>
2018-02-24 20:03       ` Tom Lane <tgl@sss.pgh.pa.us>
2018-02-24 20:12         ` Tom Lane <tgl@sss.pgh.pa.us>
2018-02-26 18:28           ` Jonathan Allen <jallen@americansavingslife.com>
2018-02-26 18:40             ` Tom Lane <tgl@sss.pgh.pa.us>
2018-02-27 21:48               ` Tom Lane <tgl@sss.pgh.pa.us>
2018-02-27 22:59                 ` Jonathan Allen <jallen@americansavingslife.com>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox