Re: [HACKERS] Our FLOAT(p) precision does not conform to spec
On 16 Jun 2003 at 18:15, Tom Lane wrote: This is a straightforward change and would not break pg_dump files, since fortunately pg_dump always references the underlying types and never refers to anything as FLOAT(p). But I wonder whether it is likely to break many existing applications. There is a hazard of some existing app asking for (what it thinks is) float8 and getting float4 instead. Especially apps. which rely on number(3) not to accept anything greate than +/- 999. I hate the syntax of putting decimal digits as range checkers in SQL field. But oracle does that and consequently lot of oracle apps rely on it. I won't be surprised if float(p) notion brings same assurance to such app developers. I think this would become and FAQ after changes are implemented. Who reads release notes anyway?..:-) Is it worth trying to provide some sort of backwards-compatibility mode? We could imagine adding a GUC variable to select binary or decimal precision, but I really don't want to. It would increase the amount of work needed by more than an order of magnitude, and this problem doesn't seem worth it. I'd rather just list this under Incompatibilities in the 7.4 release notes. Is it possible to have float-2(p) and float-10(p)? Would it be adding code sections instead of replacing it? That would be cleaner than GUC variable. Everything defaults to float-10(p) for backward compatibility for a period of a release and in 7.5, it gets switched to float-2(p). In the meantime, the behaviour remains available who cares to read the docs and notes. Just a thought.. Bye Shridhar -- Genderplex, n.: The predicament of a person in a restaurant who is unable to determine his or her designated restroom (e.g., turtles and tortoises). -- Rich Hall, Sniglets ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Our FLOAT(p) precision does not conform to spec
Shridhar Daithankar [EMAIL PROTECTED] writes: On 16 Jun 2003 at 18:15, Tom Lane wrote: This is a straightforward change and would not break pg_dump files, since fortunately pg_dump always references the underlying types and never refers to anything as FLOAT(p). But I wonder whether it is likely to break many existing applications. There is a hazard of some existing app asking for (what it thinks is) float8 and getting float4 instead. I hate the syntax of putting decimal digits as range checkers in SQL field. But oracle does that and consequently lot of oracle apps rely on it. I won't be surprised if float(p) notion brings same assurance to such app developers. You are confusing NUMERIC --- which does allow exact precision limits to be specified --- with FLOAT, which does no such thing. It has never been the case in Postgres that FLOAT(p) would restrict you to exactly p digits. The underlying implementation is that there are just two kinds of float (single and double precision) and you get whichever can hold at least p digits. This is per spec, which states that you get at least p digits, not exactly p digits. Our only problem is that whoever wrote that code failed to notice that p is supposed to be measured differently for FLOAT than for NUMERIC. AFAICT, other databases get this right (at least Oracle and DB2 do), so expectations of developers are more likely to be that we conform to the spec than that we don't. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Our FLOAT(p) precision does not conform to spec
Peter Eisentraut [EMAIL PROTECTED] writes: Considering that the data type float(x) isn't documented anywhere, I'm not worried. Good point ... I'll fix that while I'm at it ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Our FLOAT(p) precision does not conform to spec
Tom Lane writes: This is a straightforward change and would not break pg_dump files, since fortunately pg_dump always references the underlying types and never refers to anything as FLOAT(p). But I wonder whether it is likely to break many existing applications. There is a hazard of some existing app asking for (what it thinks is) float8 and getting float4 instead. Considering that the data type float(x) isn't documented anywhere, I'm not worried. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Our FLOAT(p) precision does not conform to spec
Tom Lane wrote: Is it worth trying to provide some sort of backwards-compatibility mode? We could imagine adding a GUC variable to select binary or decimal precision, but I really don't want to. It would increase the amount of work needed by more than an order of magnitude, and this problem doesn't seem worth it. I'd rather just list this under Incompatibilities in the 7.4 release notes. Let's just change it and list it in the release notes as an incompatibility --- anything else is too confusing. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
