On Wed, Nov 02, 2005 at 06:12:37PM -0500, 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 > resolution behavior. > > 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.
Thought I'd look to see if I could find anything about UNKNOWNNUMERIC, but no such luck (ISTM we really need a better way to find discussion on old ideas...) But while looking I did find this TODO, which might be relevant to the current discussion: # Change NUMERIC to enforce the maximum precision, and increase it Unfortunately I can't find any reference to that in the archives... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
