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 | CAKFQuwa6BqKfr3q2_D1PBoMqeKfKJq1BsTTD8VVU=FZT00RoSw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Add generate_series(date,date) and generate_series(date,date,integer) (Michael Paquier <michael.paquier@gmail.com>) |
| Список | pgsql-hackers |
On Thu, Mar 10, 2016 at 4:58 PM, 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 am of the same feeling, at -0.5. I don't feel like putting -1 for
this patch, as I don't really understand why this is worth adding more
complexity in the code for something that can be done with
generate_series using timestamps. Also, why only dates? And why not
other units like hours or seconds?
A date is a type, hours and seconds are not types. To use hours and seconds you need timestamp (I guess we could offer a "time" version of this function too) which we already have. Also, not choosing to implement something else generally shouldn't preclude something that exists and have genuine value from being committed.
Obviously there is some user-land annoyance at having to play with timestamp when all one really cares about is date. Given the prevalence of date usage in user-land this is not surprising.
We're not forcing anyone to review this that doesn't see that it is worth their time. We are asking th
at
the people that the community has placed in a position of authority spend some a limited amount of effort reviewing a minor addition that has been deemed desirable and that has already been reviewed and deemed something that meets the project's technical requirements. The expectation is that the amount of ongoing support this function would require is similar to that of the existing generate_series functions.
This is something that can be easily added by the user as a SQL function - its complexity cannot be so great as to be deemed a risk to the system but including its c-language variant. As you said, we already do something very similar for timestamps so the marginal complexity being added shouldn't be significant.
If you are going to -1 or -0.5 for "adds too much complexity" it would be helpful to know specifics. Scanning the thread the only real concern was dealing with infinity - which is already a complexity the current functions have so there is no "additional" there - but maybe I've missed something.
I understand Robert's position and while I find it to be community-hostile this is an open source project and so I accept that this is a possible outcome. But as soon as he asked for some +1s he got them (mostly without reasons but the reality is that the request was for desire) and a few "I vote -0.5 since my dislike is only half-baked". And the fact is that a single +1 for the idea likely represents many people at large who would use the function if present while I suspect most of those who could offer an informed -1 are already on this list. The vast majority probably don't care either way as long as we don't introduce bugs.
David J.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Alexey GrishchenkoДата:
Сообщение: Re: Endless loop calling PL/Python set returning functions