Horton

Re: BRIN minmax multi - incorrect distance for infinite timestamp/date

Tomas Vondra <tomas.vondra@enterprisedb.com>

View thread View on postgr.es
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-22T16:04:01Z
Lists: pgsql-hackers 
On 10/20/23 11:52, Ashutosh Bapat wrote:
> On Thu, Oct 19, 2023 at 6:11 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
>>
>> I think we should provide generate_series(date, date, integer) which
>> will use date + integer -> date.
> 
> Just to be clear, I don't mean that this patch should add it.
> 

I'm not against adding such generate_series() variant. For this patch
I'll use something like the query you proposed, I think.

I was thinking about the (date + interval) failure a bit more, and while
I think it's confusing it's not quite wrong. The problem is that the
interval may have hours/minutes, so it makes sense that the operator
returns timestamp. That's not what most operators do, where the data
type does not change. So a bit unexpected, but seems correct.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Fix minmax-multi distance for extreme interval values

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

  3. Fix calculation in brin_minmax_multi_distance_date

  4. Fix overflow when calculating timestamp distance in BRIN