Re: Query generates infinite loop - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Query generates infinite loop
Date
Msg-id CADkLM=dF+c2mGub1-tTK9c7OJSdK8ZdNZMURmcH8rydDcdpcyA@mail.gmail.com
Whole thread Raw
In response to Re: Query generates infinite loop  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Query generates infinite loop  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, May 9, 2022 at 12:02 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Corey Huinker <corey.huinker@gmail.com> writes:
> On Wed, May 4, 2022 at 3:01 PM Jeff Janes <jeff.janes@gmail.com> wrote:
>> On Wed, Apr 20, 2022 at 5:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Oh --- looks like numeric generate_series() already throws error for
>>> this, so we should just make the timestamp variants do the same.

> This came up once before
> https://www.postgresql.org/message-id/CAB7nPqQUuUh_W3s55eSiMnt901Ud3meF7f_96yPkKcqfd1ZaMg%40mail.gmail.com

Oh!  I'd totally forgotten that thread, but given that discussion,
and particularly the counterexample at

https://www.postgresql.org/message-id/16807.1456091547%40sss.pgh.pa.us

it now feels to me like maybe this change was a mistake.  Perhaps
instead of the committed change, we ought to go the other way and
rip out the infinity checks in numeric generate_series().

The infinite-upper-bound-withlimit-pushdown counterexample makes sense, but seems like we're using generate_series() only because we lack a function that generates a series of N elements, without a specified upper bound, something like

     generate_finite_series( start, step, num_elements )

And if we did that, I'd lobby that we have one that takes dates as well as one that takes timestamps, because that was my reason for starting the thread above.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query generates infinite loop
Next
From: Amit Kapila
Date:
Subject: Re: Logical replication timeout problem