Re: numeric hierarchy again (was Re: floor function in 7.3b2) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: numeric hierarchy again (was Re: floor function in 7.3b2)
Date
Msg-id 200210041601.g94G1sX08727@candle.pha.pa.us
Whole thread Raw
In response to numeric hierarchy again (was Re: floor function in 7.3b2)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: numeric hierarchy again (was Re: floor function in 7.3b2)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Moving to the left requires an explicit cast (or at least an assignment
> to a column).  I know this looks strange to someone who knows that our
> numeric type beats float4/float8 on both range and precision, but it's
> effectively mandated by the SQL spec.  Any combination of "exact" and
> "inexact" numeric types is supposed to yield an "inexact" result per
> spec, thus numeric + float8 yields float8 not numeric.  Another reason
> for doing it this way is that a numeric literal like "123.456" can be
> initially typed as numeric, and later implicitly promoted to float4 or
> float8 if context demands it.  Doing that the other way 'round would
> introduce problems with precision loss.  We had speculated about
> introducing an "unknown_numeric" pseudo-type to avoid that problem, but
> the above hierarchy eliminates the need for "unknown_numeric".  We can
> initially type a literal as the smallest thing it will fit in, and then
> do implicit promotion as needed.  (7.3 is not all the way there on that
> plan, but 7.4 will be.)

Do we know that defaulting floating constants will not be a performance
hit?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Threaded Sorting
Next
From: Tom Lane
Date:
Subject: Re: Return of INSTEAD rules