<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>
