On 3/17/16 11:30 AM, David G. Johnston wrote:
> On Thu, Mar 17, 2016 at 7:57 AM, Corey Huinker <[email protected]
> <mailto:[email protected]>>wrote:
>
> On Thu, Mar 17, 2016 at 10:00 AM, David Steele <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 3/17/16 4:49 AM, Dean Rasheed wrote:
>
> > On 16 March 2016 at 23:32, David Steele <[email protected]
> <mailto:[email protected]>> wrote:
> >
> >>
> >> I think in this case it comes down to a committer's judgement so I
> have
> >> marked this "ready for committer" and passed the buck on to Álvaro.
> >
> > So I was pretty much "meh" on this patch too, because I'm not
> > convinced it actually saves much typing, if any.
> >
> > However, I now realise that it introduces a backwards-compatibility
> > breakage. Today it is possible to type
> >
> > SELECT * FROM generate_series('01-01-2000'::date, '01-04-2000', '7
> days');
>
> It can also be broken as below and this is even scarier to me:
>
>
> Above and below are the same query...
Not sure I agree. My point was that even if developers were pretty
careful with their casting (or are using two actual dates) then there's
still possibility for breakage.
> postgres=# SELECT * FROM generate_series('01-01-2000'::date,
> '01-04-2000'::date, '7 days');
> ERROR: invalid input syntax for integer: "7 days"
> LINE 1: ...te_series('01-01-2000'::date, '01-04-2000'::date, '7
> days');
> <...>
>
> I see two ways around this:
>
> 1. Drop the step parameter entirely. My own use cases only ever
> require the step values 1 and -1, and which one the user wants can
> be inferred from (start < end). This would still change the output
> type where a person wanted timestamps, but instead input two dates.
>
> Undesirable.
Very undesirable. Week intervals are a very valid use case and I don't
like the automagic interval idea.
>
> 2. Rename the function date_series() or generate_series_date()
>
> I still think this is an important function because at the last
> several places I've worked, I've found myself manufacturing a query
> where some event data is likely to have date gaps, but we want to
> see the date gaps or at least have the 0 values contribute to a
> later average aggregate.
>
>
> I'd call it "generate_dates(...)" and be done with it.
>
> We would then have:
>
> generate_series()
> generate_subscripts()
> generate_dates()
To me this completely negates the idea of this "just working" which is
why it got a +1 from me in the first place. If I have to remember to
use a different function name then I'd prefer to just cast on the
timestamp version of generate_series().
Sorry, but this is now -1 from me, at least for this commitfest. While
I like the idea I think it is far too late to be redesigning such a
minor feature.
--
-David
[email protected]
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
