From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Richard Wesley <richard(at)duckdblabs(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Query generates infinite loop |
Date: | 2022-05-10 23:24:15 |
Message-ID: | CADkLM=fHZezdmrCx0mpB69UemH=frCTkyLVcs4dZ2p1b1hMh4w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
>
> 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)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-05-10 23:42:32 | Re: Query generates infinite loop |
Previous Message | Stefan Pastrilov | 2022-05-10 18:17:16 | Re: BUG #17478: Missing documents in the index after CREATE INDEX CONCURRENTLY (but existing in the table) |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-05-10 23:42:32 | Re: Query generates infinite loop |
Previous Message | Yura Sokolov | 2022-05-10 22:50:08 | Re: BufferAlloc: don't take two simultaneous locks |