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

On 16 March 2016 at 23:32, David Steele <david(at)pgmasters(dot)net> wrote:
> On 3/10/16 1:24 PM, Corey Huinker wrote:
>
>> New patch for Alvaro's consideration.
>>
>> Very minor changes since the last time, the explanations below are
>> literally longer than the changes:
>> - Rebased, though I don't think any of the files had changed in the
>> mean time
>> - Removed infinity checks/errors and the test cases to match
>> - Amended documentation to add 'days' after 'step' as suggested
>> - Did not add a period as suggested, to remain consistent with other
>> descriptions in the same sgml table
>> - Altered test case and documentation of 7 day step example so that
>> the generated dates do not land evenly on the end date. A reader
>> might incorrectly infer that the end date must be in the result set,
>> when it doesn't have to be.
>> - Removed unnecessary indentation that existed purely due to
>> following of other generate_series implementations
>
>
> As far as I can see overall support is in favor of this patch although it is
> not overwhelming by any means.
>
> 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');

and it works with just that one cast. However, this patch breaks that.

Now I'm not saying that I have used the above construct. Probably not
in fact, but maybe my work colleagues have. I honestly can't say, but
the thought of having to grep through thousands of lines of
application code to check isn't particularly appealing.

So I'm afraid it's -1 from me.

Regards,
Dean