Re: Add generate_series(date,date) and generate_series(date,date,integer)
| От | Corey Huinker |
|---|---|
| Тема | Re: Add generate_series(date,date) and generate_series(date,date,integer) |
| Дата | |
| Msg-id | CADkLM=c7GYcviSMACYvu6v2arKB0yAEMuCWs0cyUVWv3f38hRA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Add generate_series(date,date) and generate_series(date,date,integer) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Add generate_series(date,date) and generate_series(date,date,integer)
|
| Список | pgsql-hackers |
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px#ccc solid;padding-left:1ex"><br /> If it didn't respond to SIGINT, that would be an issue, but otherwise<br/> this doesn't seem much more exciting than any other way to create a<br /> query that will run longer thanyou want to wait.<br /><br /> regards, tom lane<br /></blockquote></div><br /></div><div class="gmail_extra">Itresponded to SIGINT, so yeah, meh.</div><div class="gmail_extra"><br /></div><div class="gmail_extra">Ican see value in aligning the behavior of infinity queries between date and timestamp, but I have nostrong opinion about which behavior is better: it's either set step = 0 or an ereport(), no biggie if we want to handlethe condition, I rip out the DATE_NOT_FINITE() checks.</div><div class="gmail_extra"><br /></div><div class="gmail_extra">Incidentally,is there a reason behind the tendency of internal functions to avoid parameter defaultsin favor of multiple pg_proc entries? I copied the existing behavior of the int4 generate_series, but having oneentry with the defaults seemed more self-documenting.</div><div class="gmail_extra"><br /></div><div class="gmail_extra"><br/></div></div>
В списке pgsql-hackers по дате отправления: