On Mon, May 9, 2022 at 12:02 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Corey Huinker <corey.huin...@gmail.com> writes:
> > On Wed, May 4, 2022 at 3:01 PM Jeff Janes <jeff.ja...@gmail.com> wrote:
> >> On Wed, Apr 20, 2022 at 5:43 PM Tom Lane <t...@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.
