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

On 10 March 2016 at 18:45, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Mar 10, 2016 at 11:33 AM, David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > 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.
>
> Sure, an individual function like this has almost no negative impact.
> On the other hand, working around its absence is also trivial. You
> can create a wrapper function that does exactly this in a couple of
> lines of SQL. In my opinion, saying that people should do that in
> they need it has some advantages over shipping it to everyone. If you
> don't have it and you want it, you can easily get it. But what if you
> have it and you don't want it, for example because what you really
> want is a minimal postgres installation? You can't take anything in
> core back out again, or at least not easily. Everything about core is
> expanding very randomly - code size, shared memory footprint, all of
> it. If you think that has no downside for users, I respectfully
> disagree.

Not sure what y'all are discussing, but I should add that I would have
committed this based solely upon Vik's +1.

My objection was made, then overruled; that works because the objection
wasn't "it won't work", only a preference so I'm happy.

But I still don't know "meh" means.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services