On 16 March 2016 at 23:32, David Steele <da...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers