Re: Query generates infinite loop
Corey Huinker <corey.huinker@gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Janes <jeff.janes@gmail.com>,
Richard Wesley <richard@duckdblabs.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-05-09T06:19:30Z
Lists: pgsql-bugs, pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revert "Disallow infinite endpoints in generate_series() for timestamps."
- c0406fa768ed 11.16 landed
- 86a21803c7d8 10.21 landed
- 7f0754bc4c0a 13.7 landed
- 5045c795301d 12.11 landed
- 9b5797ca54f5 14.3 landed
- 29904f5f2fda 15.0 landed
-
Disallow infinite endpoints in generate_series() for timestamps.
- e34632947008 14.3 landed
- eafdf9de06e9 15.0 landed
- e7adbd282dbf 11.16 landed
- a1e4782a0bca 10.21 landed
- 8275ba773dfe 13.7 landed
- 33fe55c06b83 12.11 landed
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.