Re: Problem with interface C++ for PostgreSQL

From: Renaud Tthonnart <thonnart(at)amwdb(dot)u-strasbg(dot)fr>
To: "Eric G(dot) Miller" <egm2(at)jps(dot)net>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Problem with interface C++ for PostgreSQL
Date: 2001-03-22 10:52:07
Message-ID: 3AB9D957.DC0DC794@amwdb.u-strasbg.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)jps(dot)net>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joseph 2001-03-22 10:55:39 Changing from rpm to Compiled version
Previous Message Marko Kreen 2001-03-22 10:02:09 Re: Call for platforms