Thread: Problem with interface C++ for PostgreSQL
Good afernoon everyone I am developping an interface C++ for a DB PostgreSQL. I am using the 'libpq++ ' library to load and save in the base. Here is my problem : to save some data in the base, we have to build a string (here : query) for these functions : Exec(char *query) or ExecTuplesOk(char* query) Then, if I want to save an integer in my DB, i have to do this : sprintf(query,"INSERT INTO myTable VALUES(...,%d,...)",myInt); myObject.ExecTupleOk(query); With integer, it is not so bad, but with float or double, the fact to convert data to string is very bad for precision. Could someone tell me how to avoid using a string to save in the DB Thank you all regards, Renaud THONNART
Hi Renaud I sent the same question to the list a few weeks ago, but I didn't get any response. If you find out how to avoid using strings, please email me. Thanks. By the way, here's an ugly way to get full precision (e.g. for a double) when building a query: ... #include <float.h> #include <string.h> ... char fmt[10]; sprintf(fmt,"%c%d.%dg\0",'%',DBL_DIG+8,DBL_DIG); ... long index=strlen(query); sprintf(query+index,fmt,double_value); ... Best Regards Brian Renaud Tthonnart wrote: > > Subject: Problem with interface C++ for PostgreSQL > Date: Wed, 21 Mar 2001 15:31:51 +0100 > From: Renaud Tthonnart <thonnart@amwdb.u-strasbg.fr> > To: "pgsql-general@postgresql.org" <pgsql-general@postgresql.org> > > Good afernoon everyone > > I am developping an interface C++ for a DB PostgreSQL. > I am using the 'libpq++ ' library to load and save in the base. > > Here is my problem : > to save some data in the base, we have to build a string (here : query) > for these functions : > > Exec(char *query) or ExecTuplesOk(char* query) > > Then, if I want to save an integer in my DB, i have to do this : > > sprintf(query,"INSERT INTO myTable VALUES(...,%d,...)",myInt); > myObject.ExecTupleOk(query); > > With integer, it is not so bad, but with float or double, the fact to > convert data to string is very bad for precision. > > Could someone tell me how to avoid using a string to save in the DB > > Thank you all > regards, Renaud THONNART > -- Brian Kurt Fujikawa Weak Interactions Group Institute for Nuclear and Particle Astrophysics Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS 50-208 Berkeley, CA 94720, USA http://bkf0.lbl.gov/fujikawa/ mailto:bkfujikawa@lbl.gov tel: +1-510-486-4398 fax: +1-510-486-6738
On Wed, Mar 21, 2001 at 03:31:51PM +0100, Renaud Tthonnart wrote:
> Good afernoon everyone
>
> I am developping an interface C++ for a DB PostgreSQL.
> I am using the 'libpq++ ' library to load and save in the base.
>
> Here is my problem :
> to save some data in the base, we have to build a string (here : query)
> for these functions :
>
> Exec(char *query) or ExecTuplesOk(char* query)
>
> Then, if I want to save an integer in my DB, i have to do this :
>
> sprintf(query,"INSERT INTO myTable VALUES(...,%d,...)",myInt);
> myObject.ExecTupleOk(query);
>
> With integer, it is not so bad, but with float or double, the fact to
> convert data to string is very bad for precision.
>
> Could someone tell me how to avoid using a string to save in the DB
I'm not sure what the C++ equivalent is, but in C the <float.h> header
usually defines the constant DBL_DIG which is the number of significant
digits in a double:
#include <stdio.h>
#include <float.h>
...
printf ("%.*f", DBL_DIG, myDouble);
...
Granted, you may get more digits of precision than really exist this
way, but at least you won't lose any. PostgreSQL will probably drop
those spurious extra digits anyway (depending on the data type).
--
Eric G. Miller <egm2@jps.net>
Thank you for your advice, Eric
Renaud THONNART
"Eric G. Miller" wrote:
> On Wed, Mar 21, 2001 at 03:31:51PM +0100, Renaud Tthonnart wrote:
> > Good afernoon everyone
> >
> > I am developping an interface C++ for a DB PostgreSQL.
> > I am using the 'libpq++ ' library to load and save in the base.
> >
> > Here is my problem :
> > to save some data in the base, we have to build a string (here : query)
> > for these functions :
> >
> > Exec(char *query) or ExecTuplesOk(char* query)
> >
> > Then, if I want to save an integer in my DB, i have to do this :
> >
> > sprintf(query,"INSERT INTO myTable VALUES(...,%d,...)",myInt);
> > myObject.ExecTupleOk(query);
> >
> > With integer, it is not so bad, but with float or double, the fact to
> > convert data to string is very bad for precision.
> >
> > Could someone tell me how to avoid using a string to save in the DB
>
> I'm not sure what the C++ equivalent is, but in C the <float.h> header
> usually defines the constant DBL_DIG which is the number of significant
> digits in a double:
>
> #include <stdio.h>
> #include <float.h>
>
> ...
>
> printf ("%.*f", DBL_DIG, myDouble);
>
> ...
>
> Granted, you may get more digits of precision than really exist this
> way, but at least you won't lose any. PostgreSQL will probably drop
> those spurious extra digits anyway (depending on the data type).
>
> --
> Eric G. Miller <egm2@jps.net>
Hi everyone ! I am writing an application in C++ that uses a base PostgreSQL. Then I use libpq++ library. I work on a SUN station Solaris 7 64 bits and I use gcc 2.95.2 to compile. To optimise my code, I use that software of Rationnal : Purify When I compile with Purify options, I get (at execution) a core dump when I use libpq++ functions. Do someone else have had that kind of problem and help me? Thank you, Renaud THONNART
Renaud Tthonnart <thonnart@amwdb.u-strasbg.fr> wrote: >I am writing an application in C++ that uses a base PostgreSQL. Then I use >libpq++ library. I work on a SUN station Solaris 7 64 bits and I use gcc >2.95.2 to compile. Are you sure the libpq++ library was compiled with that same compiler and version? In general, mixing object code generated by different C++ compilers (or versions) is asking for big trouble. Also, 2.95.3 is available now, and its fixes compared to 2.95.2 include things like :* Fix numerous problems that caused incorrect optimization in the : register reloading code. :* Fix numerous problems that caused incorrect optimization in the loop : optimizer. which IMHO are sufficient reason to upgrade to that version ASAP. >To optimise my code, I use that software of Rationnal : Purify > >When I compile with Purify options, I get (at execution) a core dump when I >use libpq++ functions. Some memory allocation debugging tools require that not just your application, but also all the libraries it uses are compiled/linked in a special way. I'm not sure Purify is among them, but it definitely cannot hurt to rebuild PostgreSQL (including libpq++) with Purify and then try again. HTH, Ray -- Do Microsoft's TCO calculations include TC of downtime?