Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> Tom> +#define NUMERIC_ABBREV_PINF NumericAbbrevGetDatum(PG_INT64_MIN)
> Tom> +#define NUMERIC_ABBREV_PINF NumericAbbrevGetDatum(PG_INT32_MIN)
> I'd have been more inclined to go with -PG_INT64_MAX / -PG_INT32_MAX for
> the NUMERIC_ABBREV_PINF value. It seems more likely to be beneficial to
> bucket +Inf and NaN separately (and put +Inf in with the "too large to
> abbreviate" values) than to bucket them together so as to distinguish
> between +Inf and "too large" values. But this is an edge case in any
> event, so it probably wouldn't make a great deal of difference unless
> you're sorting on data with a large proportion of both +Inf and NaN
> values.
I had been worried about things possibly sorting in the wrong order
if I did that. However, now that I look more closely I see that
* We convert the absolute value of the numeric to a 31-bit or 63-bit positive
* value, and then negate it if the original number was positive.
so that a finite value should never map to INT[64]_MIN, making it
safe to do as you suggest. I agree that distinguishing +Inf from NaN
is probably more useful than distinguishing it from the very largest
class of finite values, so will do it as you suggest. Thanks!
regards, tom lane
