Thread: BUG #6238: ECPG converts "long long" to long on Windows
The following bug has been logged online: Bug reference: 6238 Logged by: Jim Gray Email address: jim.gray@bull.com PostgreSQL version: 9.1.1 Operating system: Windows XP Description: ECPG converts "long long" to long on Windows Details: Postgres 9.1.1 installed on a Windows XP PC. Running ECPG with "long long" data type specified in the SQL DECLARE SECTION results in "long" being used instead. The same input file works OK on Linux with Postgres 9.0.3 Manually changing the data type to "long long" in the ECPG output file on Windows: ECPGt_long_long,&(_cpp_i_pkd1),(long)1,(long)1,sizeof(long long) -- results in run time error "unsupported data type". I am using MS Visual C++ Express 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" By the way, why is Postgres still using MSVS 2008 instead of the free MSVC 2010 Express for Windows builds?
Hi Jim, > Postgres 9.1.1 installed on a Windows XP PC. > Running ECPG with "long long" data type specified in the SQL DECLARE SECTION > results in "long" being used instead. The same input file works OK on Linux This suggests that HAVE_LONG_LONG_INT was not defined during ecpg build. Or in other words ecpg thinks long long is not supported. > with Postgres 9.0.3 Manually changing the data type to "long long" in the > ECPG output file on Windows: > ECPGt_long_long,&(_cpp_i_pkd1),(long)1,(long)1,sizeof(long long) -- results > in run time error "unsupported data type". I am using MS Visual C++ Express Did you also change the variable definition to long long? > 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. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
On Tue, Oct 4, 2011 at 8:15 AM, Michael Meskes <meskes@postgresql.org> wrot= e: > Hi Jim, > >> Postgres 9.1.1 installed on a Windows XP PC. >> Running ECPG with "long long" data type specified in the SQL DECLARE SEC= TION >> results in "long" being used instead. =A0The same input file works OK on= Linux > > This suggests that HAVE_LONG_LONG_INT was not defined during ecpg build. = Or in > other words ecpg thinks long long is not supported. > >> with Postgres 9.0.3 =A0 Manually changing the data type to "long long" i= n the >> ECPG output file on Windows: >> ECPGt_long_long,&(_cpp_i_pkd1),(long)1,(long)1,sizeof(long long) -- resu= lts >> in run time error "unsupported data type". =A0I am using MS Visual C++ E= xpress > > Did you also change the variable definition to long long? > >> 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. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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> 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. -- Ãlvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>Did you also change the variable definition to long long? Yes Michael Meskes <meskes@postgresql.org>=20 10/04/2011 05:15 AM To Jim Gray <jim.gray@bull.com> cc pgsql-bugs@postgresql.org Subject Re: [BUGS] BUG #6238: ECPG converts "long long" to long on Windows Hi Jim, > Postgres 9.1.1 installed on a Windows XP PC. > Running ECPG with "long long" data type specified in the SQL DECLARE=20 SECTION > results in "long" being used instead. The same input file works OK on=20 Linux This suggests that HAVE_LONG_LONG_INT was not defined during ecpg build.=20 Or in other words ecpg thinks long long is not supported. > with Postgres 9.0.3 Manually changing the data type to "long long" in= =20 the > ECPG output file on Windows: > ECPGt_long_long,&(_cpp_i_pkd1),(long)1,(long)1,sizeof(long long) --=20 results > in run time error "unsupported data type". I am using MS Visual C++=20 Express Did you also change the variable definition to long long? > 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"=20 to > "long" Well, this bug is (at least I don't know otherwise) fixed for more than a= =20 year. Maybe the configure test doesn't work on Windows? I don't know. Michael --=20 Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! For=E7a Bar=E7a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
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> 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? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
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/
Magnus Hagander <magnus@hagander.net> writes:
> Does ecpg have a different requirement from everything else, or are we just
> doing it differently in different places for no special reason?
I believe that in ecpg, the requirement is "support the data types
defined by the C compiler", that is we should support long long with
whatever width it actually has on the platform. Just about everyplace
else in PG, we want an integer of a known number of bits, and whether
that's long or long long is incidental. So it's not surprising to me
that this case got overlooked in the win64 patches.
regards, tom lane
On Sun, Oct 16, 2011 at 04:15:01PM -0400, Tom Lane wrote: > I believe that in ecpg, the requirement is "support the data types > defined by the C compiler", that is we should support long long with > whatever width it actually has on the platform. Just about everyplace Right. We added that to make sure we support the same embedded sql sourcecode on all systems no matter if they have long long ornot. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL