Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
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?
Wrong answer. You'll be introducing weird corner cases into the type
An approach that would actually have some credibility would be to not
resolve constants to NUMERIC right away, but to invent an UNKNOWNNUMERIC
pseudotype with coercion behavior comparable to the existing UNKNOWN
type for string literals. This has been proposed before but hasn't
really been needed so far. Of course, this converts the project from a
minor localized hack on NUMERIC into a major piece of fiddling with the
type resolution rules, with the potential for unforeseen side-effects on
the behavior of other data types. It might be worth doing anyway --- I
don't recall at the moment what problems UNKNOWNNUMERIC was intended to
solve, but if they're still open issues then it's something we ought to
get around to sometime.
Could someone please quantify how much bang we might get for what seems
like quite a lot of bucks?
I appreciate the need for speed, but the saving here strikes me as
marginal at best, unless my instincts are all wrong (quite possible)
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster