Re: Infinities in type numeric

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Infinities in type numeric
Date: 2020-06-12 13:41:56
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-06-12 14:46:14 Re: Internal key management system
Previous Message Masahiko Sawada 2020-06-12 12:53:50 Re: Transactions involving multiple postgres foreign servers, take 2