"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