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

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

"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)

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

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

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

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

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

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

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

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

I saw the release of v10.4 today and was very excited to try using the official version of ecpg, but unfortunately I'm getting the same "unsupported type "long long" on line x" error. SQL State: YE000, SQL Code: -200.

...did this fix not make it into the May release?

I guess I'm back to my custom build again. ☹

-Jonathan

-----Original Message-----
From: Jonathan Allen <jallen@americansavingslife.com>
Sent: Tuesday, February 27, 2018 3:59 PM
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
Subject: RE: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT

[This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

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<mailto:jallen@americansavingslife.com>>

Cc: Michael Meskes <meskes@postgresql.org<mailto:meskes@postgresql.org>>; Andrew Gierth <andrew@tao11.riddles.org.uk<mailto:andrew@tao11.riddles.org.uk>>; pgsql-bugs@lists.postgresql.org<mailto: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

Jonathan Allen <jallen@americansavingslife.com> writes:

I saw the release of v10.4 today and was very excited to try using the official version of ecpg, but unfortunately I'm getting the same "unsupported type "long long" on line x" error. SQL State: YE000, SQL Code: -200.
...did this fix not make it into the May release?

Well, we committed *something* about that:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=fda3e65786763bd43abc576a23035a4cd24ed138

Does that not match the fix you were using?

regards, tom lane

From: Tom Lane [mailto:tgl@sss.pgh.pa.us]

Sent: Friday, May 11, 2018 12:36 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

Jonathan Allen <jallen@americansavingslife.com> writes:

I saw the release of v10.4 today and was very excited to try using the

official version of ecpg, but unfortunately I'm getting the same
"unsupported type "long long" on line x" error. SQL State: YE000, SQL Code:
-200.

...did this fix not make it into the May release?

Well, we committed *something* about that:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=fda
3e65786763bd43abc576a23035a4cd24ed138

Does that not match the fix you were using?

I confirmed that the above commit fix the case of not define HAVE_LONG_LONG_INT.

But We found another case that causes "unsupported type "long long"" error in
Windows environment.
In our case, We got the same error "unsupported type ...", because of the flag
HAVE_STRTOLL and HAVE_STRTOULL are not defined (*1).

I created a patch which defines the above two flags in Visual Studio 2013 or greater.
# The two functions strtoll and strtoull are support from Visual Studio 2013
Please confirm the attached.

(*1)
In our case, we got the error because the below code was ignored.

src/interfaces/ecpg/ecpglib/data.c
--------------
...
#ifdef HAVE_LONG_LONG_INT
#ifdef HAVE_STRTOLL
case ECPGt_long_long:
*((long long int *) (var + offset * act_tuple)) = strtoll(pval, &scan_length, 10);
if (garbage_left(isarray, &scan_length, compat))
{
ecpg_raise(lineno, ECPG_INT_FORMAT, ECPG_SQLSTATE_DATATYPE_MISMATCH, pval);
return (false);
}
pval = scan_length;

break;
#endif /* HAVE_STRTOLL */
#ifdef HAVE_STRTOULL
case ECPGt_unsigned_long_long:
*((unsigned long long int *) (var + offset * act_tuple)) = strtoull(pval, &scan_length, 10);
if (garbage_left(isarray, &scan_length, compat))
{
ecpg_raise(lineno, ECPG_UINT_FORMAT, ECPG_SQLSTATE_DATATYPE_MISMATCH, pval);
return (false);
}
pval = scan_length;

break;
#endif /* HAVE_STRTOULL */
#endif /* HAVE_LONG_LONG_INT */
...
--------------

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

Huong Dangminh <huo-dangminh@ys.jp.nec.com> writes:

From: Tom Lane [mailto:tgl@sss.pgh.pa.us]

Well, we committed *something* about that:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=fda3e65786763bd43abc576a23035a4cd24ed138
Does that not match the fix you were using?

I confirmed that the above commit fix the case of not define HAVE_LONG_LONG_INT.

But We found another case that causes "unsupported type "long long"" error in
Windows environment.
In our case, We got the same error "unsupported type ...", because of the flag
HAVE_STRTOLL and HAVE_STRTOULL are not defined (*1).

Ah! I looked through the uses of ECPG_UNSUPPORTED, and that seems to be
the only other thing that needs to be covered.

I created a patch which defines the above two flags in Visual Studio 2013 or greater.
# The two functions strtoll and strtoull are support from Visual Studio 2013
Please confirm the attached.

It seems fairly unfortunate that this patch does not fix the problem
for as far back as MSVC has "long long" support. From what I can tell,
we could use _strtoi64 and _strtoui64 on older Windows versions. So
I'm imagining something like

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

...

#ifdef HAVE_LONG_LONG_INT_64
#define HAVE_STRTOLL 1
/* Before VS2013, use Microsoft's nonstandard equivalent function */
#if (_MSC_VER < 1800)
#define strtoll _strtoi64
#endif
#endif

and similarly for strtoull.

Please check that and see if it works.

BTW, is it possible to set up an ecpg test case to verify that this
stuff works? It'd have to handle platforms without long long though,
so I'm not sure how to deal with that.

regards, tom lane

From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
It seems fairly unfortunate that this patch does not fix the problem for
as far back as MSVC has "long long" support. From what I can tell, we could
use _strtoi64 and _strtoui64 on older Windows versions.

Thanks. You are right.
We also should fix for older VS too.

something like

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

...

#ifdef HAVE_LONG_LONG_INT_64
#define HAVE_STRTOLL 1
/* Before VS2013, use Microsoft's nonstandard equivalent function */ #if
(_MSC_VER < 1800) #define strtoll _strtoi64 #endif #endif

and similarly for strtoull.

Please check that and see if it works.

Thanks, as you mentioned the attached works fine for me.
I think the code is also fine for the before VS2013 but I not yet tested.

BTW, is it possible to set up an ecpg test case to verify that this stuff
works?
It'd have to handle platforms without long long though, so I'm not
sure how to deal with that.

Yes. I was expecting that at least bigint will works fine with sqlda in linux
system but it seem did not?
Attached test patch works fine in Windows, but in Linux system
the sqlda->sqlvar[i].sqltype return ECPGt_long but not ECPGt_long_long (as expected)
when reference to bigint column.
Is this another problem in linux? Or am I wrong something?

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

From: Huong Dangminh [mailto:huo-dangminh@ys.jp.nec.com]

something like

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

...

#ifdef HAVE_LONG_LONG_INT_64
#define HAVE_STRTOLL 1
/* Before VS2013, use Microsoft's nonstandard equivalent function */
#if (_MSC_VER < 1800) #define strtoll _strtoi64 #endif #endif

and similarly for strtoull.

Please check that and see if it works.

Thanks, as you mentioned the attached works fine for me.
I think the code is also fine for the before VS2013 but I not yet tested.

BTW, is it possible to set up an ecpg test case to verify that this
stuff works?
It'd have to handle platforms without long long though, so I'm not
sure how to deal with that.

Yes. I was expecting that at least bigint will works fine with sqlda in
linux system but it seem did not?
Attached test patch works fine in Windows, but in Linux system the
sqlda->sqlvar[i].sqltype return ECPGt_long but not ECPGt_long_long (as
expected) when reference to bigint column.
Is this another problem in linux? Or am I wrong something?

Look into the code I found that Linux also need define HAVE_LONG_LONG_INT_64
Flag in order to work with bigint and sqlda.

In the following code, sqlda_dynamic_type function return ECPGt_long,
If HAVE_LONG_LONG_INT_64 is not defined.

ecpg/ecpg/typename.c
---
sqlda_dynamic_type function
...
#ifdef HAVE_LONG_LONG_INT_64
return ECPGt_long_long;
#endif
#ifdef HAVE_LONG_INT_64
return ECPGt_long;
...
---

Is this fine if We define the above flag in pg_config.h.in like that?

---
/* Define to 1 if the system has the type `long long int'. */
-#undef HAVE_LONG_LONG_INT
+#define HAVE_LONG_LONG_INT 1

 /* Define to 1 if `long long int' works and is 64 bits. */
-#undef HAVE_LONG_LONG_INT_64
+#define HAVE_LONG_LONG_INT_64 1
---

I am wondering that "long long int" not supported platform also using pg_config.h.in?

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

Huong Dangminh <huo-dangminh@ys.jp.nec.com> writes:

Attached test patch works fine in Windows, but in Linux system the
sqlda->sqlvar[i].sqltype return ECPGt_long but not ECPGt_long_long (as
expected) when reference to bigint column.
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.

AIUI, the idea in ecpg is to support "long long int" program variables
if the compiler has such a type, without any particular assumptions about
how wide that type is. But whether the SQL type int8 maps to long or
long long is going to be platform-specific, which evidently is another
hurdle to testing anything here :-(

regards, tom lane

Huong Dangminh <huo-dangminh@ys.jp.nec.com> writes:

From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
BTW, is it possible to set up an ecpg test case to verify that this stuff
works?
It'd have to handle platforms without long long though, so I'm not
sure how to deal with that.

Yes. I was expecting that at least bigint will works fine with sqlda in linux
system but it seem did not?

After some thought I decided that the right fix is to add coverage for
both ECPGt_long and ECPGt_long_long. Any given platform will test only
one of those two code paths, but that's probably fine, because that is
the only one it would use anyway.

Pushed it that way; the buildfarm will soon tell us if this was a
stupid idea ...

regards, tom lane

I wrote:

Pushed it that way; the buildfarm will soon tell us if this was a
stupid idea ...

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.

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.

regards, tom lane