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