Horton

Re: Query generates infinite loop

Corey Huinker <corey.huinker@gmail.com>

View thread
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-10T23:24:15Z
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 →

  1. Revert "Disallow infinite endpoints in generate_series() for timestamps."

  2. Disallow infinite endpoints in generate_series() for timestamps.

>
> Less sure about that.  ISTM the reason that the previous proposal failed
> was that it introduced too much ambiguity about how to resolve
> unknown-type arguments.  Wouldn't the same problems arise here?
>

If I recall, the problem was that the lack of a date-specific
generate_series function would result in a date value being coerced to
timestamp, and thus adding generate_series(date, date, step) would change
behavior of existing code, and that was a POLA violation (among other bad
things).

By adding a different function, there is no prior behavior to worry about.
So we should be safe with the following signatures doing the right thing,
yes?:
    generate_finite_series(start timestamp, step interval, num_elements
integer)
    generate_finite_series(start date, step integer, num_elements integer)
    generate_finite_series(start date, step interval year to month,
num_elements integer)