Re: Infinities in type numeric

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> @@ -359,10 +390,14 @@ typedef struct NumericSumAccum
Tom> #define NumericAbbrevGetDatum(X) ((Datum) (X))
Tom> #define DatumGetNumericAbbrev(X) ((int64) (X))
Tom> #define NUMERIC_ABBREV_NAN NumericAbbrevGetDatum(PG_INT64_MIN)
Tom> +#define NUMERIC_ABBREV_PINF NumericAbbrevGetDatum(PG_INT64_MIN)
Tom> +#define NUMERIC_ABBREV_NINF NumericAbbrevGetDatum(PG_INT64_MAX)
Tom> #else
Tom> #define NumericAbbrevGetDatum(X) ((Datum) (X))
Tom> #define DatumGetNumericAbbrev(X) ((int32) (X))
Tom> #define NUMERIC_ABBREV_NAN NumericAbbrevGetDatum(PG_INT32_MIN)
Tom> +#define NUMERIC_ABBREV_PINF NumericAbbrevGetDatum(PG_INT32_MIN)
Tom> +#define NUMERIC_ABBREV_NINF NumericAbbrevGetDatum(PG_INT32_MAX)
Tom> #endif

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.

(It would be possible to add another bucket so that "too large", +Inf,
and NaN were three separate buckets, but honestly any more complexity
seems not worth it for handling an edge case.)

The actual changes to the abbrev stuff look fine to me.

--
Andrew (irc:RhodiumToad)