Re: SQL float types

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL float types
Date: 2000-07-08 00:09:46
Message-ID: Pine.LNX.4.21.0007072138550.587-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> > float4 => real
> > float8 => double precision

> Not just on your say-so. Arguments please?

SQL:

22)REAL specifies the data type approximate numeric, with implementation-
defined precision.

23)DOUBLE PRECISION specifies the data type approximate numeric,
with implementation-defined precision that is greater than the
implementation-defined precision of REAL.

Notice that there is no "at least" here anywhere.


> In the absence of pretty compelling reasons to change, I think
> "backwards compatibility" will have to win the day on something like
> this.

The REAL data type is not even documented. I'm evidently trying to get
people to think in terms of standard types rather than the internal,
low-level sounding names, but that won't work if the standard types aren't
really standard and the internal types don't have a standard equivalent.

Actually, if you read into the release history it says:

SQL standard-compliance (the following details changes that makes
postgres95 more compliant to the SQL-92 standard):
* the following SQL types are now built-in: smallint, int(eger), float, real,
char(N), varchar(N), date and time.

The following are aliases to existing postgres types:
smallint -> int2
integer, int -> int4
float, real -> float4
char(N) and varchar(N) are implemented as truncated text types. In
addition, char(N) does blank-padding.

So if you take that as documentation then my suggestion counts as a bug
fix. :-)

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-07-08 00:09:51 Re: Changes to handling version numbers internally
Previous Message Peter Eisentraut 2000-07-08 00:09:20 Re: libpq / SQL3