Thread: SQL float types
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? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
[ 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, Pennsylvania19026
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 greaterthan 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 implementedas 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, Pennsylvania19026
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.