From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add generate_series(date, date) and generate_series(date, date, integer) |
Date: | 2016-01-25 06:39:02 |
Message-ID: | CADkLM=c7GYcviSMACYvu6v2arKB0yAEMuCWs0cyUVWv3f38hRA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
> If it didn't respond to SIGINT, that would be an issue, but otherwise
> this doesn't seem much more exciting than any other way to create a
> query that will run longer than you want to wait.
>
> regards, tom lane
>
It responded to SIGINT, so yeah, meh.
I can see value in aligning the behavior of infinity queries between date
and timestamp, but I have no strong opinion about which behavior is better:
it's either set step = 0 or an ereport(), no biggie if we want to handle
the condition, I rip out the DATE_NOT_FINITE() checks.
Incidentally, is there a reason behind the tendency of internal functions
to avoid parameter defaults in favor of multiple pg_proc entries? I copied
the existing behavior of the int4 generate_series, but having one entry
with the defaults seemed more self-documenting.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2016-01-25 06:54:59 | Re: GIN pending list clean up exposure to SQL |
Previous Message | Dilip Kumar | 2016-01-25 06:30:56 | Re: Relation extension scalability |