Re: Re: Add generate_series(date,date) and generate_series(date,date,integer)

On 3/17/16 11:30 AM, David G. Johnston wrote:
> On Thu, Mar 17, 2016 at 7:57 AM, Corey Huinker <corey(dot)huinker(at)gmail(dot)com
> <mailto:corey(dot)huinker(at)gmail(dot)com>>wrote:
>
> On Thu, Mar 17, 2016 at 10:00 AM, David Steele <david(at)pgmasters(dot)net
> <mailto:david(at)pgmasters(dot)net>> wrote:
>
> On 3/17/16 4:49 AM, Dean Rasheed wrote:
>
> > On 16 March 2016 at 23:32, David Steele <david(at)pgmasters(dot)net <mailto:david(at)pgmasters(dot)net>> wrote:
> >
> >>
> >> I think in this case it comes down to a committer's judgement so I have
> >> marked this "ready for committer" and passed the buck on to Álvaro.
> >
> > So I was pretty much "meh" on this patch too, because I'm not
> > convinced it actually saves much typing, if any.
> >
> > However, I now realise that it introduces a backwards-compatibility
> > breakage. Today it is possible to type
> >
> > SELECT * FROM generate_series('01-01-2000'::date, '01-04-2000', '7 days');
>
> It can also be broken as below and this is even scarier to me:
>
>
> Above and below are the same query​...

Not sure I agree. My point was that even if developers were pretty
careful with their casting (or are using two actual dates) then there's
still possibility for breakage.

> postgres=# SELECT * FROM generate_series('01-01-2000'::date,
> '01-04-2000'::date, '7 days');
> ERROR: invalid input syntax for integer: "7 days"
> LINE 1: ...te_series('01-01-2000'::date, '01-04-2000'::date, '7
> days');
> <...>
>
> I see two ways around this:
>
> 1. Drop the step parameter entirely. My own use cases only ever
> require the step values 1 and -1, and which one the user wants can
> be inferred from (start < end). This would still change the output
> type where a person wanted timestamps, but instead input two dates.
>
> ​Undesirable.​

Very undesirable. Week intervals are a very valid use case and I don't
like the automagic interval idea.

>
> 2. Rename the function date_series() or generate_series_date()
>
> I still think this is an important function because at the last
> several places I've worked, I've found myself manufacturing a query
> where some event data is likely to have date gaps, but we want to
> see the date gaps or at least have the 0 values contribute to a
> later average aggregate.
>
>
> ​I'd call it "generate_dates(...)" and be done with it.
>
> We would then have:
>
> generate_series()
> generate_subscripts()
> generate_dates()

To me this completely negates the idea of this "just working" which is
why it got a +1 from me in the first place. If I have to remember to
use a different function name then I'd prefer to just cast on the
timestamp version of generate_series().

Sorry, but this is now -1 from me, at least for this commitfest. While
I like the idea I think it is far too late to be redesigning such a
minor feature.

--
-David
david(at)pgmasters(dot)net