>
> > First I wonder why the can_coerce... stuff is #if'd out of
> > parse_relation.c?
>
> Oh! That looks like my style of #if FALSE, but I can't recall why it is
> that way. Will look at it. Does it work to just substitute an #if TRUE?
> Perhaps I had it disabled during debugging, but...
Hmmm - elog(ERROR, "Type %s(%d) can be coerced to... looks
like debugging code for me. Maybe you wanted to elog(DEBUG...
?
>
> > How do other databases handle this problem. How is the
> > precision of a numeric result defined?
>
> I've enclosed some snippets from my SQL92 2nd Draft Standard doc. It
> gives you a lot of latitude :)
>
Thanks! That helps alot!
>
> d) The precision and scale of the result of division is
> implementation-defined.
I love those definitions :-)
So I'll make the display scale of a division
min( max(S1, S2), SLIMIT)
and the internal result scale
min( RMINIMUM, max(R1, R2) + 2, RLIMIT)
where S1 and S2 are the display scales of the two operands,
R1 and R2 are the internal present scales and SLIMIT, RLIMIT
is the implementation-defined maximum allowed scale at all
(what about 4000 for SLIMIT ?). The RMINIMUM is 8 to have
anything at least computed internal with 8 digits after the
decimal point (because the defaults for NUMERIC are precision
30 scale 6).
If then the result is assigned to another tuples attribute,
numeric(num,typmod) will be called and do the rounding with
the scale defined in typmod. If numeric_out(num) is called
for it, it will be output rounded to the above display scale.
With 'round(att1, 500) / att2' someone can then get the
result with 500 digits scale.
This way it is flexible enough but not to much wasted
computing is done.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #