Re: Infinite Interval

Joseph Koshakow <koshy44@gmail.com>

From: Joseph Koshakow <koshy44@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, "Gregory Stark (as CFM)" <stark.cfm@gmail.com>, jian he <jian.universality@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-04-03T00:32:26Z
Lists: pgsql-hackers

Attachments

On Sun, Apr 2, 2023 at 6:54 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>    Joseph Koshakow <koshy44@gmail.com> writes:
>    >> I've added an errcontext to all the errors of the form "X out of
>    >> range".
>
>    Please note the style guidelines [1]:
>
>        errcontext(const char *msg, ...) is not normally called directly
from
>        an ereport message site; rather it is used in error_context_stack
>        callback functions to provide information about the context in
which
>        an error occurred, such as the current location in a PL function.
>
>    If we should have this at all, which I doubt, it's probably
>    errdetail not errcontext.

I've attached a patch with all of the errcontext calls removed. None of
the existing out of range errors have an errdetail call so I think this
is more consistent. If we do want to add errdetail, then we should
probably do it in a later patch and add it to all out of range errors,
not just the ones related to infinity.

>    > How do you feel about redefining interval_mi in terms of interval_um
>    > and interval_pl? That one felt like an improvement to me even outside
>    > of the context of this change.
>
>    I did not think so.  For one thing, it introduces integer-overflow
>    hazards that you would not have otherwise; ie, interval_um might have
>    to throw an error for INT_MIN input, even though the end result of
>    the calculation would have been in range.

Good point, I didn't think of that.

Thanks,
Joe Koshakow

Commits

  1. Support +/- infinity in the interval data type.

  2. Avoid integer overflow hazard in interval_time().

  3. Guard against overflow in make_interval().

  4. Fix minmax-multi on infinite date/timestamp values

  5. Optimize various aggregate deserialization functions, take 2

  6. Remove dead code in DecodeInterval()

  7. Accept "+infinity" in date and timestamp[tz] input.

  8. Fix overflow hazards in interval input and output conversions.