"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in> 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
