Re: Add generate_series(date,date) and generate_series(date,date,integer)
От | Tom Lane |
---|---|
Тема | Re: Add generate_series(date,date) and generate_series(date,date,integer) |
Дата | |
Msg-id | 16807.1456091547@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add generate_series(date,date) and generate_series(date,date,integer) (Christoph Berg <myon@debian.org>) |
Ответы |
Re: Add generate_series(date,date) and generate_series(date,date,integer)
|
Список | pgsql-hackers |
Christoph Berg <myon@debian.org> writes: > Re: David Fetter 2016-01-26 <20160126180011.GA16903@fetter.org> >> +1 for back-patching. There's literally no case where an infinite >> input could be correct as the start or end of an interval for >> generate_series. > select * from generate_series(now(), 'infinity', '1 day') limit 10; > ... seems pretty legit to me. If limit pushdown into SRFs happened to > work some day, it'd be a pity if the above query raised an error. Oooh ... actually, that works today if you consider the SRF-in-targetlist case: regression=# select generate_series(now(), 'infinity', '1 day') limit 10; generate_series -------------------------------2016-02-21 16:51:03.303064-052016-02-22 16:51:03.303064-052016-02-23 16:51:03.303064-052016-02-2416:51:03.303064-052016-02-25 16:51:03.303064-052016-02-26 16:51:03.303064-052016-02-27 16:51:03.303064-052016-02-2816:51:03.303064-052016-02-29 16:51:03.303064-052016-03-01 16:51:03.303064-05 (10 rows) Time: 8.457 ms Given that counterexample, I think we not only shouldn't back-patch such a change but should reject it altogether. regards, tom lane
В списке pgsql-hackers по дате отправления: