On Wed, 2005-11-02 at 15:09 -0500, Tom Lane wrote:
> [ thinks for a moment... ] Actually, neither proposal is going to get
> off the ground, because the parser's handling of numeric constants is
> predicated on the assumption that type NUMERIC can handle any valid
> value of FLOAT8, and so we can get away with converting to NUMERIC on
> sight and then coercing to float later if parse analysis finds out the
> constant should be float. If the dynamic range of NUMERIC is less than
> 10^308 then this fails. So we have to find another bit somewhere, or
> the idea is dead in the water.
We convert a Value node to a Const in
backend/parser/parse_node.c:make_const
It seems straightforward enough to put in an additional test, similar to
the ones already there so that if its too big for a decimal we make it a
float straight away - only a float can be that big in that case. After
that I can't really see what the problem is?
There is only a single call where numeric_float8() is called anywhere in
the code, which is during selectivity calculations. In that case we
actually call numeric_float8_no_overflow(). If its a FLOAT8OID, then we
can simply avoid the conversion, since it already would be one.
Can you explain further? Thanks,
Best Regards, Simon Riggs
