>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.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)
