| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christoph Berg <myon(at)debian(dot)org>, David Fetter <david(at)fetter(dot)org>, Torsten Zuehlsdorff <mailinglists(at)toco-domains(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add generate_series(date,date) and generate_series(date,date,integer) |
| Date: | 2016-02-24 01:43:14 |
| Message-ID: | 56CD0AB2.9070308@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 02/22/2016 08:04 PM, Corey Huinker wrote:
> >
> > Given that counterexample, I think we not only shouldn't back-patch such a
> > change but should reject it altogether.
>
> Ouch, good point. The overflows are a different problem that we had
> better address though (still on my own TODO list)...
>
>
> So I should remove the bounds checking from
> generate_series(date,date,[int]) altogether?
I feel rather uneasy about simply removing the 'infinity' checks. Is
there a way to differentiate those two cases, i.e. when the
generate_series is called in target list and in the FROM part? If yes,
we could do the check only in the FROM part, which is the case that does
not work (and consumes arbitrary amounts of memory).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2016-02-24 02:14:50 | Re: [HACKERS] JDBC behaviour |
| Previous Message | Armor | 2016-02-24 01:30:54 | Fw: Re: get current log file |