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

On Thu, Mar 10, 2016 at 11:45 AM, 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?

I'd rather cater to the people who are content that everything in
PostgreSQL is of high quality and ignore those things that they have no
immediate need for - and then are happy to find out that when they have a
new need PostgreSQL already provides them well thought-out and tested tool
that they can use.

We purport to be highly extensible but that doesn't preclude us from being
well-stocked at the same time.

And by not including these kinds of things in core the broader ecosystem is
harmed since not every provider or PostgreSQL services is willing or
capable of allowing random third-party extensions; nor is adding 20
"important and generally useful to me but an annoyance to the project"
functions to every database I create a trivial exercise. But it is trivial
to ignore something that exists but that I have no need for.

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.

Attempts to limit that expansion seemingly happen "very randomly" as well.​

If there is a goal and demand for a "minimalist" installation then we don't
seem to have anything going on that is actively trying to make it a
reality. I'm likely being a bit myopic here but at the same time the
increased footprint from JSON, parallel queries, and the like dwarf the
contribution a handful of C-language functions would add.

I do understand why more trivial features are scrutinized the way they are
but I still hold the opinion that features such as this should generally be
given the benefit of inclusion unless there are concrete technical concerns.

David J.