Horton

Re: Infinite Interval

Dean Rasheed <dean.a.rasheed@gmail.com>

View thread View on postgr.es
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: jian he <jian.universality@gmail.com>, Joseph Koshakow <koshy44@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, "Gregory Stark (as CFM)" <stark.cfm@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-09-22T08:09:12Z
Lists: pgsql-hackers 
On Fri, 22 Sept 2023 at 08:49, Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Following code in ExecInterpExpr makes it clear that the
> deserialization function is be executed in per tuple memory context.
> Whereas the aggregate's context is different from this context and may
> lives longer that the context in which deserialization is expected to
> happen.
>

Right. I was about to reply, saying much the same thing, but it's
always better when you see it for yourself.

> Hence I have changed interval_avg_deserialize() in 0007 to use
> CurrentMemoryContext instead of aggcontext.

+1. And consistency with other deserialisation functions is good.

> Rest of the patches are
> same as previous set.
>

OK, I'll take a look.

Regards,
Dean

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.