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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Add generate_series(date,date) and generate_series(date,date,integer)
Дата
Msg-id CAKFQuwbDqZptJmqNXQG8iO=-ecbiOaC1b6dNWhtBRH05=pG69Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add generate_series(date,date) and generate_series(date,date,integer)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Mar 10, 2016 at 11:45 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Mar 10, 2016 at 11:33 AM, David G. Johnston
<david.g.johnston@gmail.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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Patch to implement pg_current_logfile() function
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: WIP: Detecting SSI conflicts before reporting constraint violations