Обсуждение: libpq: Newbie help w/ data type conversions on queries and updates
I'm coming from a Java background, so I'm relatively new to C/C++ in general. I want to convert the data retrieved from a field to an "external" data type I can use; specifically a datetime or a timestamp. It looks like the only option for retrieving field data is as raw bytes, but I haven't found any information on mapping those byte streams to structures. Also, is there any sort of a libpq API, or are you just stuck with perusing header files? I had zero luck following the build instructions for libpqxx on Windows, so it looks like libpq is my only option for now. -- Marvin Keith Bellamy Software Engineer Innovision Corporation 913.438.3200
> I'm coming from a Java background, so I'm relatively new to C/C++ in > general. I want to convert the data retrieved from a field to an > "external" data type I can use; specifically a datetime or a timestamp. > It looks like the only option for retrieving field data is as raw bytes, > but I haven't found any information on mapping those byte streams to > structures. Actually, values are delivered as C-style strings by default. So it may help get a feel for things if you print a few of them out to the console. > Also, is there any sort of a libpq API, or are you just stuck with > perusing header files? In C and C++, header files are normally the way to define an API. > I had zero luck following the build instructions for libpqxx on Windows, > so it looks like libpq is my only option for now. Perhaps that can be fixed. What problems did you run into, and using which compiler exactly? Jeroen
jtv@xs4all.nl wrote: >>I'm coming from a Java background, so I'm relatively new to C/C++ in >>general. I want to convert the data retrieved from a field to an >>"external" data type I can use; specifically a datetime or a timestamp. >>It looks like the only option for retrieving field data is as raw bytes, >>but I haven't found any information on mapping those byte streams to >>structures. >> >> > >Actually, values are delivered as C-style strings by default. So it may >help get a feel for things if you print a few of them out to the console. > > > I think I figured this out. What I wanted was a way to read binary representations of field data and know the format. I found the "Base Types In C-Language Functions" section that lists the formats and where they're defined in the header files. I also found the PQexecParams method which lets you query for binary data instead of text data. Your comment about default string format is what triggered my comprehension. >>I had zero luck following the build instructions for libpqxx on Windows, >>so it looks like libpq is my only option for now. >> >> > >Perhaps that can be fixed. What problems did you run into, and using >which compiler exactly? > > >Jeroen > > > I'm building for MSVC 7.1.3088, VS .NET 2003 on Win XP. I copied the compiler headers and pointed the common file attributes to my PostgreSQL install and I get this error: [snip] ..\src\util.cxx(60) : warning C4244: 'initializing' : conversion from 'double' to 'const float', possible loss of data ..\src\util.cxx(60) : error C2124: divide or mod by zero NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\nmake.exe"' : return code '0x2' Stop. I was able to build libpqxx with cygwin (which probably uses gcc), but it produced libpqxx.la and libpqxx.a. Since my IDE is Visual Studio .NET 2003, I'm not sure if I can use them in a MSVC app (mind you I'm still learning about native development as a Java developer). This was a very manual process and I had to move a lot of files around to accomodate the default locations the build process expected to find files (not knowing how to reset them with parameters). -- Marvin Keith Bellamy Software Engineer Innovision Corporation 913.438.3200
Marvin Bellamy <marvin.bellamy@innovision.com> wrote: > I'm building for MSVC 7.1.3088, VS .NET 2003 on Win XP. I copied the > compiler headers and pointed the common file attributes to my PostgreSQL > install and I get this error: > > [snip] > ..\src\util.cxx(60) : warning C4244: 'initializing' : conversion from > 'double' to 'const float', possible loss of data > ..\src\util.cxx(60) : error C2124: divide or mod by zero Ah, that's a bit of workaround code for compilers that don't have proper ways of producing NANs. The sample configuration headers for your compiler don't say yet whether those proper ways are available, so the code assumes the worst and reverts to divide-by-zero (strictly at compile time, mind you, so neither the warning or the error is really appropriate) to generate NaNs. Easiest fix: define the PQXX_HAVE_QUIET_NAN preprocessor macro. If that doesn't work (i.e. if the compiler doesn't provide quiet_NaN()), define PQXX_HAVE_NAN instead. I can release an update over the coming days that fixes this, once I'm sure about what works. > I was able to build libpqxx with cygwin (which probably uses gcc), but > it produced libpqxx.la and libpqxx.a. Since my IDE is Visual Studio > .NET 2003, I'm not sure if I can use them in a MSVC app (mind you I'm > still learning about native development as a Java developer). This was Correct on both counts: cygwin uses gcc, and you can't link object files or libraries (they're actually almost the same thing) from one C++ compiler with those of another. The latter is one of the more annoying aspects of life with C++, and there are complex but good reasons for this restruction--although thankfully some standardization is happening. Jeroen
jtv@xs4all.nl wrote: >Marvin Bellamy <marvin.bellamy@innovision.com> wrote: > > > >>I'm building for MSVC 7.1.3088, VS .NET 2003 on Win XP. I copied the >>compiler headers and pointed the common file attributes to my PostgreSQL >>install and I get this error: >> >>[snip] >>..\src\util.cxx(60) : warning C4244: 'initializing' : conversion from >>'double' to 'const float', possible loss of data >>..\src\util.cxx(60) : error C2124: divide or mod by zero >> >> > >Ah, that's a bit of workaround code for compilers that don't have proper >ways of producing NANs. The sample configuration headers for your >compiler don't say yet whether those proper ways are available, so the >code assumes the worst and reverts to divide-by-zero (strictly at compile >time, mind you, so neither the warning or the error is really appropriate) >to generate NaNs. > >Easiest fix: define the PQXX_HAVE_QUIET_NAN preprocessor macro. If that >doesn't work (i.e. if the compiler doesn't provide quiet_NaN()), define >PQXX_HAVE_NAN instead. I can release an update over the coming days that >fixes this, once I'm sure about what works. > > > Defining the PQXX_HAVE_QUIET_NAN macro allowed the build to complete successfully. Thanks!