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

On Thu, Mar 10, 2016 at 8:58 AM, 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 tend to think we err toward this too much. This seems like development
concerns trumping usability. Consider that anything someone took the time
to write and polish to make committable to core was obviously genuinely
useful to them - and for every person capable of actually taking things
that far there are likely many more like myself who cannot but have
encountered the, albeit minor, usability annoyance that this kind of
function seeks to remove.

I really don't care that the codebase is marginally larger or that there is
another few records in the catalog - I hope that our code organization and
performance is capable of handling it (and many more).

The overhead of adding an entirely new concept to core would give me more
pause in that situation but this function in particular simply fleshes out
what the user community sees to be a minor yet notable lack in our existing
offering of the generate_series() feature. Its threshold for meeting
"genuinely" should be considerably lower than for more invasive or complex
features such as those that require entirely new syntax (e.g., the recently
rejected ALTER ROLE patch) to implement.

If something can be done with a user-defined function on stock PostgreSQL,
especially for concepts or features we already have, the decision to commit
a c-language function that someone else has written and others have
reviewed should, IMO, be given the benefit of assumed usefulness.

My $0.02

David J.