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

On 16 March 2016 at 23:32, David Steele <david@pgmasters.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