pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: BRIN minmax multi - incorrect distance for infinite timestamp/date
Date: Sun, 22 Oct 2023 18:04:01 +0200
Message-ID: <3e21dbbe-3613-6012-ee15-aee3db9674af@enterprisedb.com> (raw)
In-Reply-To: <CAExHW5vHphNHqkkdORzFfSdTg3Puijbd0SQvf0LrD_TsQb1WJA@mail.gmail.com>
References: <eef0ea8c-4aaa-8d0d-027f-58b1f35dd170@enterprisedb.com>
	<75de1895-3bd9-242e-cf13-3f5b0281e676@enterprisedb.com>
	<CAEZATCV0kY0gWCLChf_x_Drh4KUEKcmBPD+cggcSju6yHaRYYA@mail.gmail.com>
	<CAExHW5tsrfu3k5We1tr_ANaQ_0OJc6Zf2YMB+TkmB2PQwirAPQ@mail.gmail.com>
	<dd7fcf77-414b-b4b2-358a-0fc505255fba@enterprisedb.com>
	<CAExHW5vcq6mJJRH3wPytDataDw+HZgs-E7b=e+SXpWgo7BoTsg@mail.gmail.com>
	<31400145-6f71-a6b2-e371-048a8e1584ef@enterprisedb.com>
	<CAExHW5vi3Yjk_5vvwtZWrvy-ZWbx68hbET_GpyH5fjS=2KMZrw@mail.gmail.com>
	<575aa0fe-311d-d3d0-1f1a-abb1b9665a63@enterprisedb.com>
	<CAExHW5vThLf2BKHYfj5SJjsrotHe-zaDiZwS0k27BW_FP4nXaA@mail.gmail.com>
	<a4d5563f-b62a-61aa-8022-12eed3fbcf21@enterprisedb.com>
	<CAExHW5vaO71q9JMY5Lkm-qHht1=y4PzH0rQBKR0hiAmU62w+PA@mail.gmail.com>
	<768756b0-7598-6b69-2646-6db6dbe8511b@enterprisedb.com>
	<CAExHW5vY+BCoRdrvLjYtCvDvNmGEKEWN+jgen_TMNwqh0=d1Wg@mail.gmail.com>
	<CAExHW5vHphNHqkkdORzFfSdTg3Puijbd0SQvf0LrD_TsQb1WJA@mail.gmail.com>

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





view thread (27+ messages)  latest in thread

Message-ID: <3e21dbbe-3613-6012-ee15-aee3db9674af@enterprisedb.com>
Permalink:  ../3e21dbbe-3613-6012-ee15-aee3db9674af@enterprisedb.com/
Also on:    postgresql.org/message-id/3e21dbbe-3613-6012-ee15-aee3db9674af@enterprisedb.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@enterprisedb.com, ashutosh.bapat.oss@gmail.com, dean.a.rasheed@gmail.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: BRIN minmax multi - incorrect distance for infinite timestamp/date
  In-Reply-To: <3e21dbbe-3613-6012-ee15-aee3db9674af@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox