SQL float types

[ Charset ISO-8859-1 unsupported, converting... ]

The parser currently maps the type REAL to float8. I contend that it
should be float4.

float4 => real
float8 => double precision

Is this based on the standard documents?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Peter Eisentraut <peter_e@gmx.net> writes:

The parser currently maps the type REAL to float8. I contend that it
should be float4.

float4 => real
float8 => double precision

Can we make this change?

Not just on your say-so. Arguments please?

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

regards, tom lane

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@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

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.

You have convinced me.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Peter Eisentraut <peter_e@gmx.net> writes:

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.

Good point.

The REAL data type is not even documented.

It isn't? In that case the compatibility argument isn't as pressing
as I thought. OK, I'm convinced.

Actually, if you read into the release history it says:
The following are aliases to existing postgres types:
float, real -> float4

Actually, "float" without any precision spec defaults to float8 at the
moment, so both parts of this item in the history are wrong.

BTW, are you arguing to change the float->float8 default? I think that
would be a bad idea. Offhand I don't see anything in SQL that mandates
a particular default precision for FLOAT.

regards, tom lane

PS: I seem to recall some unhappiness about the ODBC driver's mappings
between Postgres float types and the ODBC type codes. You might want
to check that while you are at it.