From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AW: type conversion discussion |
Date: | 2000-05-18 03:26:30 |
Message-ID: | 21373.958620390@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> So it would have to be more like this
> int2 -> int4 -> int8 -> numeric
> float4 -> float8 -> numeric
> This tree is "correct" in the above sense but has a number of obvious
> problems.
The most fundamental of which is that it violates SQL92: combining
exact and approximate numerics is supposed to yield approximate
(ie, float), not exact.
> float[x] + numeric would now yield numeric. The solution is making an
> explicit float8+numeric function. Okay, so at the end it's actually more
> like 8 functions, but that's a price I'd be willing to pay. (Perhaps the
> commutator mechanism could be extended to cover different types as well.)
Make that 8 functions for each and every one of the numeric operators.
I don't think that's reasonable... especially since those operators
cannot cause the overflow problem to go away. (The SQL guys probably
did not foresee people implementing NUMERIC with wider range than FLOAT
;-) ... but the fact that we did so doesn't give us license to ignore
that aspect of the spec ...)
> numeric, any int/float operations would be promoted to numeric/numeric,
> which is in any case the right thing to do.
No it isn't. See above.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2000-05-18 03:37:10 | Re: 7.0 RPMS and syslog problem. (more) |
Previous Message | Tom Lane | 2000-05-18 03:18:54 | Re: pg_dump return failed sanity check |