Re: Reducing the overhead of NUMERIC data - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reducing the overhead of NUMERIC data
Date
Msg-id 10595.1130973157@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reducing the overhead of NUMERIC data  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Reducing the overhead of NUMERIC data
Re: Reducing the overhead of NUMERIC data
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> 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.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Reducing the overhead of NUMERIC data
Next
From: Robert Creager
Date:
Subject: Re: Assert failure found in 8.1RC1