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 CAKFQuwZMCRUoqG+PwLXpKfs58Urzyjs1qgirvne_Cozx24-hbA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add generate_series(date,date) and generate_series(date,date,integer)  (Robert Haas <robertmhaas@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 8:58 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 10 March 2016 at 06:53, Michael Paquier <michael.paquier@gmail.com>
> wrote:
>>
>> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera
>> <alvherre@2ndquadrant.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.

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Endless loop calling PL/Python set returning functions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Is there a way around function search_path killing SQL function inlining?