Stephan Szabo wrote:
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.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.
ok! :)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)
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.
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.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 issuesbrought 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.
---------------------------(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
