Re: Query generates infinite loop
| От | Corey Huinker |
|---|---|
| Тема | Re: Query generates infinite loop |
| Дата | |
| Msg-id | CADkLM=dF+c2mGub1-tTK9c7OJSdK8ZdNZMURmcH8rydDcdpcyA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Query generates infinite loop (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Query generates infinite loop
|
| Список | 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.
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 по дате отправления: