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

On Thu, Mar 10, 2016 at 9:30 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Thu, Mar 10, 2016 at 4:58 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> > On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs <simon(at)2ndquadrant(dot)com>
> wrote:
> >> On 10 March 2016 at 06:53, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
> >> wrote:
> >>>
> >>> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
> >>> <alvherre(at)2ndquadrant(dot)com> wrote:
> >>> > Robert Haas wrote:
> >>> >> I'm pretty meh about the whole idea of this function, though,
> >>> >> actually, and I don't see a single clear +1 vote for this
> >>> >> functionality upthread. (Apologies if I've missed one.) In the
> >>> >> absence of a few of those, I recommend we reject this.
> >>> >
> >>> > +1
> >>>
> >>> I'm meh for this patch.
> >>
> >>
> >> "meh" == +1
> >>
> >> I thought it meant -1
> >
> > In my case it meant, like, -0.5. I don't really like adding lots of
> > utility functions like this to the default install, because I'm not
> > sure how widely they get used and it gradually increases the size of
> > the code, system catalogs, etc. But I also don't want to block
> > genuinely useful things. So basically, I'm not excited about this
> > patch, but I don't want to fight about it either.
>
> I am of the same feeling, at -0.5. I don't feel like putting -1 for
> this patch, as I don't really understand why this is worth adding more
> complexity in the code for something that can be done with
> generate_series using timestamps. Also, why only dates? And why not
> other units like hours or seconds?
>

​A date is a type, hours and seconds are not types. To use hours and
seconds you need timestamp (I guess we could offer a "time" version of this
function too) which we already have. Also, not choosing to implement
something else generally shouldn't preclude something that exists and have
genuine value from being committed.

Obviously there is some user-land annoyance at having to play with
timestamp when all one really cares about is date. Given the prevalence of
date usage in user-land this is not surprising.

We're not forcing anyone to review this that doesn't see that it is worth
their time. We are asking th
​at​
the people that the community has placed in a position of authority spend
some a limited amount of effort reviewing a minor addition that has been
deemed desirable and that has already been reviewed and deemed something
that meets the project's technical requirements.
​ The expectation is that the amount of ongoing support this function
would require is similar to that of the existing generate_series functions.​

​This is something that can be easily added by the user as a SQL function -
its complexity cannot be so great as to be deemed a risk to the system but
including its c-language variant. As you said, we already do something
very similar for timestamps so the marginal complexity being added
shouldn't be significant.

If you are going to -1 or -0.5 for "adds too much complexity" it would be
helpful to know specifics. Scanning the thread the only real concern was
dealing with infinity - which is already a complexity the current functions
have so there is no "additional" there - but maybe I've missed something.

I understand Robert's position and while I find it to be community-hostile
this is an open source project and so I accept that this is a possible
outcome. But as soon as he asked for some +1s he got them (mostly without
reasons but the reality is that the request was for desire) and a few "I
vote -0.5 since my dislike is only half-baked". And the fact is that a
single +1 for the idea likely represents many people at large who would use
the function if present while I suspect most of those who could offer an
informed -1 are already on this list. The vast majority probably don't
care either way as long as we don't introduce bugs.

David J.