Stephan Szabo wrote:
On Wed, 30 Oct 2002, Pedro Miguel Frazao Fernandes Ferreira wrote:
I understand that if people insert a value of 1.1 in a double, they want
to get 1.1 without knowing that in fact the stored number is
1.10000000000000009. But do you understand that if some people insert,
for example, a value of 1.79769313486231571e+308 they dont want to get
1.79769313486232e+308 which does not compare equal (in Matlab or C) to
the first ? This is a bug.


I disagree to some extent.  I'm not sure it's meaningful to expect that
(what if the database and the client are on different architectures) in
general.  In any case, you're effectively going from decimal
representation to double to decimal representation (the string you used
to insert it -> internal representation -> string used to output it) and
that's only guaranteed to be correct up to DBL_DIG digits as far as I can
tell.  I think it'd be nice to have an option to get more digits for those
sorts of applications, however.
In the previous email example, in C, I was going from decimal to double and so on, but this is not the case when I do some simulation. In this case it will allways be from Matlab double to PostgreSQL float8 and from libpq PQgetvalue() string to Matlab double. The example was just a x86 number example where (got the string from Matlab double) query output would fail.

This would probably make sense as an option, so why don't you look at the
past discussions and see if you can come up with a solution that keeps
everyone happy (and preferably implement it, but...) :)
but ???
, but I realize that you might not be interested in doing such. (I figured
the last part was implied)
ok! :)

No problem. I have seen the GUC thing in the source (guc.c etc...) and it
does not look too dificult. It has lots of examples in the code itself.
What I am saying is that I can do it if pg-people agree on the (some) way to do it.

To have parameters, say DOUBLE_FORMAT and FLOAT_FORMAT, which could have
 option values of 'SHORT' and 'LONG'.
Option 'SHORT' would be default and produce the standard sprintf(ascii,...
Option 'LONG' would produce sprintf(ascii, "%25.18g", num).

Other way would be to have number parameters to be used in the sprintf
calls, in place of 25 and 18, in the format string.

From what Tom said, something similar was suggested and there were issues
brought up.  I don't know what they were, since I wasn't personally
terribly interested, but it should be in the archives.  If there were any
concerns, you'll probably need to deal with those as well.
I looked at some of these emails and it seemed to me that the problem was that Tom did'nt want a parameter that would force people to know about printf number formatting. I think the first solution above (the SHORT and LONG way) is simple, maintains usual output as default and enables 'maximum' precision at request.


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])



--
----------------------------------------------------------------------
Pedro Miguel Frazao Fernandes Ferreira
Universidade do Algarve
Faculdade de Ciencias e Tecnologia
Campus de Gambelas
8000-117 Faro
Portugal
Tel./Fax:  (+351) 289 800950 / 289 819403
http://w3.ualg.pt/~pfrazao


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Reply via email to